At 2:12 PM +0200 8/8/05, Michael Schwendt wrote:
>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.
No, I'm adding new information to the Release tag. This is recommended
practice for all packagers: to put an attribution in the Release tag so
that it is possible to know that different releases have incomparable
numbers. I didn't think this up myself; I read it in various rpm docs.
There isn't a Repository tag. One could be added to rpm and yum and
everything else, and over time it could start being used. That probably
won't happen. Adding the recommended packager information to the Release
tag, in a useful form that inidicates the repository it came from can be
done now.
>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.
No, they are not for branding, and serve that purpose poorly, if that is
what you use them for. The only useful purpose for putting the packager or
repo in the Release tag is to serve notice that two Release tag values are
or are not comparable.
>If you want a mixture between dist tags and repo tags, that would only
>increase the infamous problem of "RPM dependency hell".
No. Currently, different repos can include a package with the same
name-version-release, even when the packages contain different (security or
bug-fix) patches, becuase each repo has had that many different builds of
the package. Currently such packages compare as equal, or even a package
with later patches can compare as older just because that repo didn't
release as often.
>> 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.
They don't actually mean what you want them to mean.
>instead of adding information into RPM's Release field which doesn't
>belong into it.
No, the Release tag is supposed to contain the packager in some way, so
that one can tell that releases that might seem to be the same are actually
not comparable.
>> 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.
No, as soon as somebody adds a package to extras that previously existed in
third-party repos that makes cooperation more like "cooperation" with the
Police ("Confess! or you aren't cooperating.").
Making sure that the Release tag clearly indicates whether two values can
be compared makes cooperation less trouble, as it makes problems with
comparing packages explicit at install or upgrade time, rather than just
waiting for bugs to show up later.
>> 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?
Uhh, yum contacts the user through stderr. Why would yum want to bother
some repo owner?
>> 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.
Uhh, I my package has only a 1 in its Release tag, and another package has
only a 1 in its Release tag, you say that now they don't compete? This is
not my understanding. I think they compete as if they were equal, when in
fact they are not comparable.
With a repo tag appended, it becomes possible for yum et.al. to know that
the two "1"s are not comparable. Yum (and rpm and everything else)
presently just compare incomparable releases and pick one as newer, when in
fact they have no way of telling, and should ask for help if they really
need to know. They could also even resolve some of these issues
themselves, by noting that the dependency comes from a particular repo and
that it can be resolved by that repo, and in such cases the Release
/number/ is not relevent.
____________________________________________________________________
TonyN.:' <mailto:tonynelson@xxxxxxxxxxxxxxxxx>
' <http://www.georgeanelson.com/>
