The repository scoring problem - a proposal

Ralf Ertzinger fedora at camperquake.de
Sun Mar 12 15:21:01 UTC 2006


Hi.

Every one in a while the problem of repository scoring comes up (maybe
under a different name, but I chose this one): The wish of users to
give different RPM repositories different "rights" with respect to the
packages that can be installed from the various sources, mostly to prevent
third party repositories from replacing packages installed by the core
operating system.

This post is not about discussing whether this is a good idea or not.
I personally think this is a valid tool, but I can see that there may
be other views about it.

A core problem in this context is that while it is possible to determine
where a package comes from at installation time this information is lost
during installation, all packages installed on a system are "equal" in
that there is no way to tell where they originally came from, thus making
the scoring mentioned above hard to impossible.

It has been proposed to add a field to the RPM file headers that can
be set by the packager to indicate where the package came from. This requires
work on the behalf of all packagers/repositories, and is thus not likely
to work (in my opinion), or it will take a long time to actually show effect.

I hereby propose a diffenent path. Do not add repository information to
the RPM files (or do it anyway, it is useful information after all, just
not suited for the problem at hand) but change the RPM libraries to enable
programs installing packages (be it RPM itself, yum, smart or whatever)
to add metadata to the installed package. The installing program knows
best where it got the package it is just installing, after all, so
it can add the information itself.

This has the following pros and cons:

Pro:
* If implemented, it works right now (except for packages already installed,
  but other approaches have that problem, too)
* It requires no work on the behalf of the packagers
* It is stable against repositories changing their repository id (if
  such a field is added, see above)

Cons:
* It may not be stable against certain configuration changes in
  the package managing program (if, for example, yum uses it's internal
  repositoryid to tag packages a change to that id would create
  some problems)
* Using different programs to manage your packages at the same time will
  probably not work, since they will not recognize the tags written by
  each other.
* I do not know if such a change can be made while retaining backwards
  compatibility to older RPM versions (if this is desired, that is)


I'd like to hear your thoughts about this. And maybe there are other ideas
of what can be done with user addable metadata in the RPM package DB.




More information about the fedora-devel-list mailing list