Legend:

RepodataLocations

There have been way too many discussions about putting repodata in places other than as repository metadata. This is a terrible idea, and this article will tell you why:

4

5

== Current situation ==

6

7

Currently a lot of third party repositories have the bare yum repodata, which is:

8

9

* repomd.xml (index)

10

* primary

11

* filelists

12

* other

13

14

...this is the most minimal thing you can generate if you run [createrepo] and all of the above are basically direct conversions of the rpm package headers. However if you look at a significant repo. like Fedora then there are a bunch of extra things:

15

16

* groups

17

* updateinfo

18

* pkgtags

19

20

...the interesting thing to note here is that although this data relates to the current package set, '''none of the above''' can be obtained directly from the packages. It's also true that none of the above are created via. [createrepo], they are just added to the repodata via. [modifyrepo].

21

22

There is also one "special" piece of data that is not distrubted via. repodata, but via. a package:

23

24

* specspo

25

26

...and a lot of the reasons for opposing any new repodata that is distributed outside of the repository metadata is because of experience with this package and the fact it causes nothing but problems.

27

28

=== Using repodata, what are the downsides? ===

29

30

At a minimum repodata can be considered much like a package, with a single very important difference '''it is always in sync. with the repomd.xml you have'''. This doesn't mean that the repodata needs to be download more often than if it was in a package (Eg. if groups doesn't change when you get a new repomd.xml, yum just keeps the old one). It can also still be used offline, and it is '''always correct'''. There is '''no''' downside to using repodata, from the users point of view.

31

32

This is mostly how updateinfo and groups etc. are distributed now, a single file is generated and then after you create the repository you run [modifyrepo] to add the file. There are then low level interfaces in yum (and I assume other packaging solutions) to just say "give me a pointer to the updateinfo repodata". There are also higher level APIs, for current repodata like updateinfo, but they aren't required. So there is '''no''' downside to using repodata, from an application developers point of view.

33

34

=== Using packages, what are the downsides? ===

35

36

As pointed out above, the big problem with putting metadata in packages is that you have to keep it synchronized with the repository. There is currently no code within yum to do any synchronization of "package metadata" and all of the current pieces of extra repodata have multiple users (and all proposed new repodata I've seen will almost certainly have multiple users). This means that '''even if you could''' keep the repodata synchronized, you'd have to do that from multiple applications instead of it just working from one. However it's very unlikely that you can keep it synchronized, here are the obvious known problems:

37

38

* Nothing is stagnant. This was one of the assumptions for "specspo", when it was first put in a package, is that package summary and descriptions don't change that often. This is somewhat true when you are talking about 2,000 packages that don't change much, but completely divorced from reality when you have 20,000 packages 50% of which will get an update during their lifetime. specspo is always at least slightly wrong currently, and I can't think of any repodata that would fare better.

39

40

* Packages are installed. This means to change the version of repodata you are looking at '''you need to change the system'''. There are many usecases for repodata where this is hard, and some where it's basically impossible including:

41

42

i. anaconda

43

i. preupgrade

44

i. yum --installroot

45

i. yum --releasever

46

i. yum --enablerepo

47

i. repoquery --archlist

48

i. yum blah (esp. as non-root, but even as root there are trust issues)

49

i. any tools to do "intelligent" mirroring.

50

i. any tools to do repository creation based on one or more other repositories.

51

52

...even in the best case of a GUI application which has direct access to root, '''and''' has some kind of ACL system to distinguish between these "safe" repodata packages and "unsafe" normal packages the choices are still not good. You can either silently install the repodata update (thus. silently altering the users system), or you can choose one of various ways to say "Press this button to install something, which is required for correct operation".

53

To be fair there is one known application (abrt) that does download packages, but does not install them. However I have not seen any proposals to use "packaged repodata" in this manner.

54

55

* There is always more than one repo. As the previous point noted, there are significant problems with repodata in packages when you enable/look-at a repo. for the first time. However there are other edge cases involving multiple repos. like:

Otherwise known as "Why isn't specspo replaced?" The problem is that as soon as there is some solution, esp. for something like repodata that wasn't important enough to be added within the last 10 years+, it doesn't matter how bad the solution is and how much pain it causes over the long term. Specifically talking about specpos agaon, there have been numerous designs to fix it but the fact you have to convert all the code that "understands specspo" (and be "compatible") is a giant barrier to deploying a fix.

64

65

To put it another way, if specspo had been blocked, yum would have done fully localized searches years ago. Which is a huge value loss to users.

66

67

== Not a single use case ==

68

69

There have been some arguments that "this is fine, because only app. XYZ will use it." I can only assume the people saying this are deluding themselves or trying to delude others. I know of at least 5 different plans for extra repodata, and for the ones yum is less likely to use directly there are 3-4 beta. programs/applications that want to use it.