On Mon, 8 Aug 2005 11:08:58 -0400, Tony Nelson wrote:
> 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.
Where can those pieces of documentation be found?
Different releases of a package are distinguishable already after
increasing the number in the "Release:" field. There is no need whatsoever
to add all kinds of letters to that field. Why should packages built
at livna.org for Fedora Core 4 contain "Li4" and not simply "fc4"?
> There isn't a Repository tag.
So? Why "At#" and "Li#" in your examples then?
> >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.
WRT the latter, when would that be? -- They are always (!) compared with
eachother for any two equally named packages in the transaction set.
> >If you want a mixture between dist tags and repo tags, that would only
> >increase the infamous problem of "RPM dependency hell".
>
> No.
But of course, because of the following:
> 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.
Yes, that's one of the problems with "mixing repositories". The only
way to avoid that is to eliminate overlapping content in repositories
and keep all versions of package "foo" in sync with a base repository.
> >> 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.
What do they mean? And where is it written that e.g. Fedora Extras
must not let their build system set
Packager: Fedora Extras (...)
or similar?
>
> >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,
First time I hear that.
> so
> that one can tell that releases that might seem to be the same are actually
> not comparable.
You keep repeating this, but it is wrong and doesn't buy us anything.
Every bit in a package's release field is taken into account during RPM
version comparison. RPM, Yum, Apt-RPM, all the tools compare the entire
release string in order to find out whether a package is newer than
another one. Adding arbitrary letters to a Release tag only makes the
RPM version comparison more false.
> >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.").
So? If a packager notices that an RPM for the package, which he wants to
contribute to Extras, is already included in a different repository, he is
no longer permitted to contribute his package to Extras?
> 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.
No, see above. The package version that may be seen as "newer" might
not be newer or more complete or more bug-fixed actually.
> >> 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?
Why do you try to emphasise with things like "Uhh"? Surely Yum would need
to decide what information to print? What would Yum print in case of
a Core package conflicting with a kde-redhat package? It would not
make any sense to print Core developer contact information when the
Core packager is innocent.
> 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.
Right, welcome to the dangers of repository mixing. NEVR is equal, but
content may be different.
> With a repo tag appended, it becomes possible for yum et.al. to know that
> the two "1"s are not comparable.
Once and for all, no part of the Release field is treated specially during
RPM version comparison.
> 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.
If this is supposed to go into the directing of Apt-pinning, SmartPM,
repository priorities, or things like that, I believe it is a dead end.
Overlapping content in multiple repositories is dangerous. The solution
to the problem is to use the same base packages.
