Hi all,
On my rawhide system, I noticed that there are a lot of packages with inconsistent tags. There are (numbers in brackets are for packages built in the past 14 days): - 369 (216) packages with fc8 in the release tag (shouldn't we be using f8?) - 354 (1) packages with fc7 in the release tag - 205 (27) packages with no fedora version in the release tag - 42 (0) packages with fc6 in the release tag
- 465 (0) packages with Vendor: Red Hat, Inc - 431 (244) packages with Vendor: Fedora Project - 74 (0) packages with Vendor: Koji
- 465 (0) packages with Packager: Red Hat, Inc. http://bugzilla.redhat.com/bugzilla - 363 (244) packages with Packager: Fedora Project - 74 (0) packages with Packager: Koji - 68 (0) packages with Packager: Fedora Project http://bugzilla.redhat.com/bugzilla
- 437 (244) packages with Distribution: Unknown - 369 (0) packages with Distribution: Red Hat (FC-7) - 90 (0) packages with Distribution: Red Hat (FC-6) - 68 (0) packages with Distribution: Fedora Extras - 6 (0) packages with Distribution: (none)
- 759 (243) packages with Signature: (none) - 81 (0) packages with Signature: fd372689897da07a (Red Hat Beta?) - 72 (1) packages with Signature: b44269d04f2a6fd2 (Fedora?) - 58 (0) packages with Signature: 82ed95041ac70ce6 (Extras?)
Obviously a lot of these packages haven't gone through the build system of late, but even the ones that have still show a few inconsistencies. Is this something that is being worked on?
n0dalus.
"n" == n0dalus n0dalus+redhat@gmail.com writes:
n> Hi all, On my rawhide system, I noticed that there are a lot of n> packages with inconsistent tags. There are (numbers in brackets are n> for packages built in the past 14 days):
n> 369 (216) packages with fc8 in the release tag (shouldn't we be n> using f8?)
No, it's fc8. f8 would sort less than fc7, causing badness.
n> 354 (1) packages with fc7 in the release tag 205
Well, the old packages are just fine; there's no reason for the tag to change if the package isn't rebuilt. The new one is troubling. Maybe someone tried to build with an outdated common directory, or perhaps there some other issue with the buildsys.
n> (27) packages with no fedora version in the release tag
What's wrong with that?
n> 42 (0) packages with fc6 in the release tag
What's wrong with that?
- J<
On Sun, 2007-06-24 at 22:20 -0400, Simo Sorce wrote:
What about changing it to be fr8 (Fedora Release 8) ? Would that make more sense than keeping around a meaningless 'c' ?
The "c" is not meaningless. The "FC" acronym now means "Fedora Collection" rather than "Fedora Core" in this case of the tags. :)
On Sun, 24 Jun 2007 22:20:58 -0400, Simo Sorce wrote:
On Sun, 2007-06-24 at 20:31 -0500, Jason L Tibbitts III wrote:
No, it's fc8. f8 would sort less than fc7, causing badness.
What about changing it to be fr8 (Fedora Release 8) ? Would that make more sense than keeping around a meaningless 'c' ?
It would create some more confusion, since ".fr" used to be a repo tag at freshrpms.net.
Le Lun 25 juin 2007 09:13, Michael Schwendt a écrit :
On Sun, 24 Jun 2007 22:20:58 -0400, Simo Sorce wrote:
On Sun, 2007-06-24 at 20:31 -0500, Jason L Tibbitts III wrote:
No, it's fc8. f8 would sort less than fc7, causing badness.
What about changing it to be fr8 (Fedora Release 8) ? Would that make more sense than keeping around a meaningless 'c' ?
It would create some more confusion, since ".fr" used to be a repo tag at freshrpms.net.
actually it could be fe as in fedora everything if we insist on keeping this term (I'd rather have fedora collection used instead of everything myself, since it's much less english-specific)
On 24 Jun 2007 20:31:22 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
n> 369 (216) packages with fc8 in the release tag (shouldn't we be n> using f8?)
No, it's fc8. f8 would sort less than fc7, causing badness.
I know, but its still undesirable to need to put 'fc' in every package of every release from this point on. Could packages be moved over to f8 by using release numbers, epochs or some other rpm hack?
n> (27) packages with no fedora version in the release tag
What's wrong with that?
Technically nothing, but my point was that its inconsistent.
n0dalus.
On Mon, 2007-06-25 at 12:04 +0930, n0dalus wrote:
On 24 Jun 2007 20:31:22 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
n> 369 (216) packages with fc8 in the release tag (shouldn't we be n> using f8?)
No, it's fc8. f8 would sort less than fc7, causing badness.
I know, but its still undesirable to need to put 'fc' in every package of every release from this point on. Could packages be moved over to f8 by using release numbers, epochs or some other rpm hack?
No.
- ajax
Adam Jackson wrote:
On Mon, 2007-06-25 at 12:04 +0930, n0dalus wrote:
On 24 Jun 2007 20:31:22 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
n> 369 (216) packages with fc8 in the release tag (shouldn't we be n> using f8?)
No, it's fc8. f8 would sort less than fc7, causing badness.
I know, but its still undesirable to need to put 'fc' in every package of every release from this point on. Could packages be moved over to f8 by using release numbers, epochs or some other rpm hack?
No.
Couldn't we tag all packages built *from this point on* with f8? New builds have to bump the EVR anyway, so 2.f8 is still greater than 1.fc7. The whole "f8 is rpm-less than fc7" argument is only valid if you assume no other changes to a package's EVR when being rebuilt, but AFAIK there's never been a package rebuilt in fedoraland where the disttag was the only thing that was bumped. Granted, that means there would be a mix of 'fc' and 'f' packages, but that's no more tacky than our current fc6+fc7 mix.
-Brandon
On Tuesday 26 June 2007 10:22:33 Brandon Holbrook wrote:
Couldn't we tag all packages built *from this point on* with f8? New builds have to bump the EVR anyway, so 2.f8 is still greater than 1.fc7. The whole "f8 is rpm-less than fc7" argument is only valid if you assume no other changes to a package's EVR when being rebuilt, but AFAIK there's never been a package rebuilt in fedoraland where the disttag was the only thing that was bumped. Granted, that means there would be a mix of 'fc' and 'f' packages, but that's no more tacky than our current fc6+fc7 mix.
Many cases the same version-release were built on multiple branches. frobitz-1.2 comes out and we want to release it across all of Fedora. Therefor we can have frobitz-1.2-1%{dist} on each branch and it will automagically calculate to
frobitz-1.2-1.fc6 frobitz-1.2-1.fc7 frobitz-1.2-1.fc8
Now, if we used your suggestion and made it just f8, suddenly the frobitz-1.2-1.f8 version is /lower/ than the frobitz-1.2-1.fc7 version. Broken upgrade path.
Jesse Keating wrote:
On Tuesday 26 June 2007 10:22:33 Brandon Holbrook wrote:
Couldn't we tag all packages built *from this point on* with f8? New builds have to bump the EVR anyway, so 2.f8 is still greater than 1.fc7. The whole "f8 is rpm-less than fc7" argument is only valid if you assume no other changes to a package's EVR when being rebuilt, but AFAIK there's never been a package rebuilt in fedoraland where the disttag was the only thing that was bumped. Granted, that means there would be a mix of 'fc' and 'f' packages, but that's no more tacky than our current fc6+fc7 mix.
Many cases the same version-release were built on multiple branches. frobitz-1.2 comes out and we want to release it across all of Fedora. Therefor we can have frobitz-1.2-1%{dist} on each branch and it will automagically calculate to
frobitz-1.2-1.fc6 frobitz-1.2-1.fc7 frobitz-1.2-1.fc8
Now, if we used your suggestion and made it just f8, suddenly the frobitz-1.2-1.f8 version is /lower/ than the frobitz-1.2-1.fc7 version. Broken upgrade path.
I'm sure I'm saying something stupid, but isn't an upgrade path like that 1) "unlikely" to happen while packages get updated every now and then, and thus will have a complete upgrade path at some point, while 1.2-1.fc7 is installed on a machine that gets update 1.2-2.f8 2) not used by anaconda upgrade -i'm not sure about this one ;-) 3) used only by the not-recommended yum upgrade -again, the "only" part I'm not sure about 4) completely unnecessary while both .fc7 and f8 programs have the same version number, source and are built with the same spec 5) easily fixed by bumping the release number for the 'later' package 6) happening regularly with like dev/udev, libata, stuff like that?
I'm sure I'm missing something that prevents 'f8' being the dist-tag, I'm no release engineer after all. These are just things that come to my mind.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
I'm sure I'm missing something that prevents 'f8' being the dist-tag, I'm no release engineer after all. These are just things that come to my mind.
Perhaps the strongest reasons not to change or worry the dist tag are:
a) it has non-zero costs (in that it causes upgrade path issues, etc) b) it provides nothing but some very mild cosmetic value (to some) c) it has been discussed here previously and decided that the fc means fedora collection d) there are far more pressing issues to work on
On Tuesday 26 June 2007 10:48:57 Jeroen van Meeuwen wrote:
I'm sure I'm saying something stupid, but isn't an upgrade path like that 1) "unlikely" to happen while packages get updated every now and then, and thus will have a complete upgrade path at some point, while 1.2-1.fc7 is installed on a machine that gets update 1.2-2.f8
The same version-release gets applied across the branches fairly often. This is not a made up scenario.
2) not used by anaconda upgrade -i'm not sure about this one ;-)
We're talking about enabling anaconda upgrades to make use of external repos at upgrade time, in which case this very much /would/ be used by anaconda upgrade.
3) used only by the not-recommended yum upgrade -again, the "only" part I'm not sure about
While not upgraded, it is something we try hard to make at least possible. Part of that is ensuring we don't break upgrade paths.
4) completely unnecessary while both .fc7 and f8 programs have the same version number, source and are built with the same spec
Not so. Each branch could have different tool sets (gcc), different rpm version creating the package, etc.. Or in the case of python you could be seeing a completely different location on the file system (python2.4 vs python2.5)
5) easily fixed by bumping the release number for the 'later' package
Why needlessly "fork" the spec file when the majority of the value of dist tags lies in being able to use the identical spec across the branches?
6) happening regularly with like dev/udev, libata, stuff like that?
How is this happening regularly? We're very against breaking upgrade paths in RPM NVRs. rel-eng just passed a vote that requires rpm nvr paths to be upgradeable at any stage of Fedora development.
I'm sure I'm missing something that prevents 'f8' being the dist-tag, I'm no release engineer after all. These are just things that come to my mind.
On Tue, 2007-06-26 at 16:48 +0200, Jeroen van Meeuwen wrote:
Jesse Keating wrote:
On Tuesday 26 June 2007 10:22:33 Brandon Holbrook wrote:
Couldn't we tag all packages built *from this point on* with f8? New builds have to bump the EVR anyway, so 2.f8 is still greater than 1.fc7. The whole "f8 is rpm-less than fc7" argument is only valid if you assume no other changes to a package's EVR when being rebuilt, but AFAIK there's never been a package rebuilt in fedoraland where the disttag was the only thing that was bumped. Granted, that means there would be a mix of 'fc' and 'f' packages, but that's no more tacky than our current fc6+fc7 mix.
Many cases the same version-release were built on multiple branches. frobitz-1.2 comes out and we want to release it across all of Fedora. Therefor we can have frobitz-1.2-1%{dist} on each branch and it will automagically calculate to
frobitz-1.2-1.fc6 frobitz-1.2-1.fc7 frobitz-1.2-1.fc8
Now, if we used your suggestion and made it just f8, suddenly the frobitz-1.2-1.f8 version is /lower/ than the frobitz-1.2-1.fc7 version. Broken upgrade path.
I'm sure I'm saying something stupid, but isn't an upgrade path like that
- "unlikely" to happen while packages get updated every now and then,
Nope, converse it very frequent. Wrt. to former FE packages, I'd say it's the "rule".
and thus will have a complete upgrade path at some point, while 1.2-1.fc7 is installed on a machine that gets update 1.2-2.f8 2) not used by anaconda upgrade -i'm not sure about this one ;-) 3) used only by the not-recommended yum upgrade -again, the "only" part I'm not sure about 4) completely unnecessary while both .fc7 and f8 programs have the same version number, source and are built with the same spec
Consider the rpms can differ internally (may use different paths, different compilers, might have different deps etc.)
- easily fixed by bumping the release number for the 'later' package
- happening regularly with like dev/udev, libata, stuff like that?
I'm sure I'm missing something that prevents 'f8' being the dist-tag,
yes, f8 is not safe against rebuilding from the same spec:
# fedora-rpmvercmp Epoch1 :0 Version1 :1 Release1 :1.fc7 Epoch2 :0 Version2 :1 Release2 :1.f8 0:1-1.fc7 is newer
Ralf
On Tue, 2007-06-26 at 16:48 +0200, Jeroen van Meeuwen wrote:
Jesse Keating wrote:
On Tuesday 26 June 2007 10:22:33 Brandon Holbrook wrote:
Couldn't we tag all packages built *from this point on* with f8? New builds have to bump the EVR anyway, so 2.f8 is still greater than 1.fc7. The whole "f8 is rpm-less than fc7" argument is only valid if you assume no other changes to a package's EVR when being rebuilt, but AFAIK there's never been a package rebuilt in fedoraland where the disttag was the only thing that was bumped. Granted, that means there would be a mix of 'fc' and 'f' packages, but that's no more tacky than our current fc6+fc7 mix.
Many cases the same version-release were built on multiple branches. frobitz-1.2 comes out and we want to release it across all of Fedora. Therefor we can have frobitz-1.2-1%{dist} on each branch and it will automagically calculate to
frobitz-1.2-1.fc6 frobitz-1.2-1.fc7 frobitz-1.2-1.fc8
Now, if we used your suggestion and made it just f8, suddenly the frobitz-1.2-1.f8 version is /lower/ than the frobitz-1.2-1.fc7 version. Broken upgrade path.
I'm sure I'm saying something stupid, but isn't an upgrade path like that
- "unlikely" to happen while packages get updated every now and then,
and thus will have a complete upgrade path at some point, while 1.2-1.fc7 is installed on a machine that gets update 1.2-2.f8
If I update the fc7 branch at the same time as the f8 branch I have this transition:
yesterday | today foo-1.2-1.fc7 | foo-1.2-2.fc7 foo-1.2-1.fc8 | foo-1.2-2.f8
In order to fix that we'd need to change the disttag on all Fedora branches to f# at the same time. So we'd have 1.f7, 1.f6, etc.
-Toshio
On Tue, 2007-06-26 at 14:38 +0000, Kevin Kofler wrote:
Jason L Tibbitts III <tibbs <at> math.uh.edu> writes:
No, it's fc8. f8 would sort less than fc7, causing badness.
Uhm, does fc10 sort greater than fc9? Because if not, disttag chaos is only ~1.5 years away.
benzedrine:~% fedora-rpmvercmp 0 0 0.fc9 0 0 0.fc10 0:0-0.fc10 is newer
- ajax
On Sunday 24 June 2007 21:14:32 n0dalus wrote:
Hi all,
On my rawhide system, I noticed that there are a lot of packages with inconsistent tags. There are (numbers in brackets are for packages built in the past 14 days):
- 369 (216) packages with fc8 in the release tag (shouldn't we be using
f8?)
No, fedora collection 8.
- 354 (1) packages with fc7 in the release tag
We still inherit many Fedora 7 builds. Unless there is a good technical reason to rebuild them we don't waste resources in rebuilding just for a cosmetic package version.
- 205 (27) packages with no fedora version in the release tag
dist tag is optional. In many cases it is preferred to /not/ have one, like data files that won't change from release to release. No sense in rebuilding them all the time, just update the oldest supported release first, and all the newer collections will inherit it.
- 42 (0) packages with fc6 in the release tag
Again, we still inherit some packages all the way back to fc6. If there is significant technical reason to rebuild then they would be, but cosmetics is not a reason.
- 465 (0) packages with Vendor: Red Hat, Inc
Built internally as part of "Core"
- 431 (244) packages with Vendor: Fedora Project
Built with Koji and/or Plague IIRC
- 74 (0) packages with Vendor: Koji
Built with Koji for a short period of time where we lost the Vendor definitions. Not a reason to rebuild, they'll pick up the new Vendor tag next time they're built for a real reason.
- 465 (0) packages with Packager: Red Hat, Inc.
http://bugzilla.redhat.com/bugzilla
- 363 (244) packages with Packager: Fedora Project
- 74 (0) packages with Packager: Koji
- 68 (0) packages with Packager: Fedora Project
See above response, same thing going on here.
- 437 (244) packages with Distribution: Unknown
This may be the only actual problem I see here. Perhaps we lost Distribution definition in our current koji setup. I'll investigate.
369 (0) packages with Distribution: Red Hat (FC-7)
90 (0) packages with Distribution: Red Hat (FC-6)
68 (0) packages with Distribution: Fedora Extras
6 (0) packages with Distribution: (none)
759 (243) packages with Signature: (none)
81 (0) packages with Signature: fd372689897da07a (Red Hat Beta?)
72 (1) packages with Signature: b44269d04f2a6fd2 (Fedora?)
58 (0) packages with Signature: 82ed95041ac70ce6 (Extras?)
Inheritance once again, and we don't automatically sign Rawhide builds at this time.
Obviously a lot of these packages haven't gone through the build system of late, but even the ones that have still show a few inconsistencies. Is this something that is being worked on?
I only saw one issue above that needs any attention, and that's the Distribution tag.