On Sun, 7 Aug 2005 15:55:56 -0400, Tony Nelson wrote:
> Fedora's packages sometimes include FC# (FC3, FC4) as part of the Release
> field. If all packages included some such thing in the Release we would
> have a much easier time sorting such stuff out. All packages from Fedora
> would have FC# or FE#, all packages from Livna might have Li# (or LiS#,
> LiU#, and LiT#) or some such, ATRPMs might be At#, and so on.
You're mixing different types of tags here.
The FC# tags you refer to are "dist tags" (distribution tags). When they
are not used to only denote the distribution a package was built for,
their numeric part is the important one since it allows for a proper
upgrade path. For online updates only. For CD-based upgrades, it needs
more than that.
Tags like "lvn", "rf", "fr", "at", "fdr" a different. They are "repo tags"
(repository tags). They serve no purpose other than branding a package
file name and--unfortunately--having an influence on RPM version-release
comparison. The more such different repo tags exist, the more upgrade
races are created between repositories. For instance, but not limited to:
"fc3" is newer than than "FC4", "FE3" is newer than "At4", "Li4" is newer
than "At4". And of course, "FE" > "FC", and so on.
If you want a mixture between dist tags and repo tags, that would only
increase the infamous problem of "RPM dependency hell".
> Currently,
> packages normally contain Packager and Vendor tags, but these don't
> actually specify the repository.
Which is even more reason to start using these fields,
$ rpm --query kernel --qf %{packager}\\n%{vendor}\\n
Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Red Hat, Inc.
instead of adding information into RPM's Release field which doesn't
belong into it.
> Alternatively, RPM could be modified to have a new tag in the preamble, but
> I think that would be more difficult all around. Extending the sometime
> practice of marking packages with FC# would be something that could be done
> by each packager independently, with a minimum of cooperation.
I fail to see how repo tags would make cooperation easier. Cooperation
would be simplified if common based packages were duplicated without
modifying/rebuiling them. As soon as somebody considers it necessary to
rebuild/rename/modify a package, this raises questions and makes
cooperation or coordination more difficult.
> Once it looked like this was happening, the tools like yum could be
> extended to make some use of it in resolving or reporting conflicts.
How does Yum know which party to contact?
> I plan to mark my own packages with my initials (Release: 1_GAN). It's not
> perfect, but it should be good enough.
The old scheme from fedora.us was superior and is still used at Livna.org,
although the "lvn" tag could go (if not be moved to the very right
position where it would be least-significant). It used a prefix of "0" in
the release field, which increases the likelihood that a package which
enters Core (or Extras) and starts with "1" is seen as newer. Adding
"_GAN" into the mix makes it compare and compete with every other
repository which provides a package with the same name, but a different
release, maybe just a reasonable "1" for the first package release.
