Hi,
I am planing to release a couple of rpms which are supposed to be add-on packages to Fedora Core and/or Fedora Extras.
What is the current convention on choosing rpm release tags for such packages to provide co-existence for such kind of packages?
AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist such kind of convention. Conversely, all seem to be designed "to take over the system".
Ralf
Ralf Corsepius wrote:
Hi,
I am planing to release a couple of rpms which are supposed to be add-on packages to Fedora Core and/or Fedora Extras.
What is the current convention on choosing rpm release tags for such packages to provide co-existence for such kind of packages?
AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist such kind of convention. Conversely, all seem to be designed "to take over the system".
http://www.fedora.us/wiki/PackageSubmissionQAPolicy http://www.fedora.us/wiki/PackageNamingGuidelines If you follow these rules you generally will not clash with FC packages, but it takes a little practice to get it right. The other volunteers will help you if you make mistakes, so don't worry. It would help if you submit your packages to fedora.us QA just so other people know it exists. (That process will NOT become easier when the SCM goes online, because only trusted & proven developers will have any checkin access at all, while everyone else must earn that trust through demonstrated hard work and dedication.)
I assume you mean by "taking over the system" you mean replacing packages that are within the core distribution? fedora.us and livna does not do that at all. The other 3rd party repositories are controlled by single persons and they generally do whatever they want unilaterally, for better or worse.
Warren
On Tue, May 11, 2004 at 10:11:42PM -1000, Warren Togami wrote:
Ralf Corsepius wrote:
I am planing to release a couple of rpms which are supposed to be add-on packages to Fedora Core and/or Fedora Extras.
What is the current convention on choosing rpm release tags for such packages to provide co-existence for such kind of packages?
AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist such kind of convention.
We tried to discuss this here, but there wasn't much interest from Red Hat's side, as Red Hat is always focusing on the latest release and resolves concurrent builds for different distros (whenever they happen) on an as needed basis (so each time the solution is different, sometimes without a tag, sometimes with a tag like "FC1" and so on).
The main idea is to have a scheme that does not apply to the scope of this one distribution and this current time window. It should apply on FC, RHL, RHEL and why not Mandrake/SuSE, whatever.
So the general stance is to have a suffux to the release tag containing an rpm-sortable disttag and an optional repotag, like
foo-1.2.3-4.rh9.ralf.src.rpm
So the release tag looks like
<buildid><distid><distversion><repotag_opt>
where buildid shound end with digits (for example a simple integer like "3", or something conatining cvs info like "0.cvs20040512.16"), distid should be invariant for the family of distributions and distversion should be rpm-sortable (7.3, 8.0, 9 for instance). Repotag is placed at the least significant place wrt to rpm comparison and is optional.
Nobody objected this scheme above, but the implementation was difficult, given the constraint, that FC should be considered as a successor to RHL in rpm upgrade path terms. So the disttag to FC needed to be rpm-higher than that of RHL.
A solution used by currently most free repos is to have "rh" for RHL and "rhfc" for FC. It works very well, but some (Warren ;) disliked the association with rh in FC rpms and decided to find another solution. Current rpm (2003 upwards) sort digits above letters, so a trick/kludge is used in fedora.us' convention to ensure upgradability, the distid in the scheme above is completely dropped.
There is no perfect scheme, and you need to choose for yourself. I wished there would ba a scheme that would allow for
foo-1.2.3-4.fc1.ralf.src.rpm
without breaking too much the schemes for RH9 downwards. A suggestion that was dropped here and died in silence, was to use fc0.9 for rh9 to make it fit into this scheme, e.g. declaring RHL as a 0-dot predecessor to FC. But again that was politicaly non-correct. :(
Anyway, RHx are all past EOL and perhaps it is time to consider a scheme that is clan for FC ("fc1", "fc2", ...) and obfuscates RHL releases. Anything that is rpm-smaller than "fc", e.g. let it start with a-e, or maybe indeed the "fc0." distid for RHL.
Conversely, all seem to be designed "to take over the system".
Even though this is our secret obsession, what do you man by that?
I assume you mean by "taking over the system" you mean replacing packages that are within the core distribution? fedora.us and livna does not do that at all. The other 3rd party repositories are controlled by single persons and they generally do whatever they want unilaterally, for better or worse.
I am sure for better, but I am biased :)
It is funny that the single-person-controlls-all was the main argument for the free repos leaving fedora.us last year ...
FWIW AFAIK all free repos accept submissions of packages and also help you in setting up your repo, if that is what you want to do.
On Wed, 12 May 2004 11:31:04 +0200, Axel Thimm wrote:
So the general stance is to have a suffux to the release tag containing an rpm-sortable disttag and an optional repotag, like
foo-1.2.3-4.rh9.ralf.src.rpm
Which is a bad suggestion, because the package %release version should begin at 0, so any other version of the package which might appear in Fedora Core would serve as an upgrade of this add-on.
On Wed, May 12, 2004 at 01:02:43PM +0200, Michael Schwendt wrote:
On Wed, 12 May 2004 11:31:04 +0200, Axel Thimm wrote:
So the general stance is to have a suffux to the release tag containing an rpm-sortable disttag and an optional repotag, like
foo-1.2.3-4.rh9.ralf.src.rpm
Which is a bad suggestion, because the package %release version should begin at 0, so any other version of the package which might appear in Fedora Core would serve as an upgrade of this add-on.
for one it is a simple suggestion, I didn't want to have cvs pre-alpha builds with kernel modules discussed, but give the general idea.
Of course, just as version cut-off moved to the disttags, you can have hierarchical buildtags, like <vendor>_<3rd party> build structures, leading to things like foo-1.2.3-4_5.rh9.ralf.src.rpm or foo-1.2.3-0_5.rh9.ralf.src.rpm, if the vendor does not yet offer foo in version 1.2.3.
For packages not existing in FC and where it looks like it will take some time to get them in (or perhaps will by definition not ever make it), I suggest to not use hierarchical tags, as it is easier to ask the "man-inside" to use a higher build.
This answer has become lengthy. The essential part is at the end of this mail :-)
On Wed, 2004-05-12 at 11:31, Axel Thimm wrote:
On Tue, May 11, 2004 at 10:11:42PM -1000, Warren Togami wrote:
Ralf Corsepius wrote:
I am planing to release a couple of rpms which are supposed to be add-on packages to Fedora Core and/or Fedora Extras.
What is the current convention on choosing rpm release tags for such packages to provide co-existence for such kind of packages?
AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist such kind of convention.
We tried to discuss this here, but there wasn't much interest from Red Hat's side, as Red Hat is always focusing on the latest release and resolves concurrent builds for different distros (whenever they happen) on an as needed basis (so each time the solution is different, sometimes without a tag, sometimes with a tag like "FC1" and so on).
Though not having participated, I recall these discussions and wish they would have come to a satisfactory conclusion ;)
The main idea is to have a scheme that does not apply to the scope of this one distribution and this current time window. It should apply on FC, RHL, RHEL and why not Mandrake/SuSE, whatever.
In an ideal world, yes.
But I have given in hope vendors can agree on a common naming scheme and am focusing on Fedora Core and Fedora US/Extras.
So the general stance is to have a suffux to the release tag containing an rpm-sortable disttag and an optional repotag, like
foo-1.2.3-4.rh9.ralf.src.rpm
AFAICT, this approach considers upgrades between distros, but it does not consider replacing RH supplied Core packages or nor replacing Fedora.US supplied packages nor does it consider replacing "local packages" with Fedora.US supplied packages.
A solution used by currently most free repos is to have "rh" for RHL and "rhfc" for FC.
Hmm? Fedora uses 0.fdr.<...>.1 , freshrpms used fr and now seems to have switched to using 'fc1.fr', you seem to be using rhfc, packman (No FC1 rpms there yet, but I am involved there) uses '<vendor-release>.pm', ... finally there are Ximian and JPackage ... and ...
It works very well, but some (Warren ;) disliked the association with rh in FC rpms and decided to find another solution.
Well, I want somebody being in charge (be it RH or Fedora.US) to give an official recommendation ;)
All I read on the "old Fedora Project" home page (http://www.fedora.us/wiki/PackageNamingGuidelines) is: ... C-4. Dist tag ... 0.fdr.%{X}.%{disttag} ...
AFAIS, this doesn't match with what Fedora.US currently ships: 0.fdr.%{disttag}.%{X}
It also does not seem to cover conventions on * Replacement packages * 3rd party add-on packages both wrt. FedoraCore/RedHat and FedoraCore/RedHat+Fedora.US.
In my understanding, for replacement packages the "leading 0" must match the FC/RH version the package is supposed to replace, while third party packages are supposed to use a custom %{disttag}, while leaving the rest of the Fedora.US release-tag intact.
Let's try to apply the GuideLines to an example: A package of mine requires perl-XML-LibXML-Common.
Neither Fedora Core 1 nor Fedora.US ship perl-XML-LibXML-Common, but Fedora Core 2 has it. There is a package proposal pending for months in Fedora.US's QA to add perl-XML-LibXML-Common to Fedora.US/FC1, but ATM it is not available for FC1.
As I want to release my "pkg" for FC1 *now*, I'd have to release a perl-XML-LibXML-Common legacy package for FC1 *now*. However, I actually do not want to maintain a perl-XML-LibXML-Common myself and want the Fedora.US/FC1-Extras package to replace mine, once it will/should be released.
How to choose the "release-tag" for my "temporary legacy package", that an upgrade from FC1->FC2 will replace my perl-XML-LibXML-Common rpm with that shipped with FC2 and that a potential release of perl-XML-LibXML-Common by Fedora.US will replace my package?
* FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm * Thereofore I'd expect a potential FC1-Extras/Legacy package to be named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.
Now, which release-tag to use for my "temporary legacy package"?
As it seems to me, the only functional solution for my purposes is: perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm
For example: perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm
Ralf
On Wed, 12 May 2004 15:44:53 +0200, Ralf Corsepius wrote:
All I read on the "old Fedora Project" home page (http://www.fedora.us/wiki/PackageNamingGuidelines) is: ... C-4. Dist tag ... 0.fdr.%{X}.%{disttag} ...
AFAIS, this doesn't match with what Fedora.US currently ships:
It does. %{disttag} is the target distribution and evaluates to rh80, rh90, 1, 2, and so on. %{X} is what you increase with each package revision. Example:
foo-1.0-0.fdr.4.rh80
%X = 4 %disttag = rh80
It also does not seem to cover conventions on
- Replacement packages
Do you mean upgrades of what is included within Fedora Core? Obviously, %release must be higher than the current %release of the package in Fedora Core, but preferably lower than the next security Update.
- 3rd party add-on packages
both wrt. FedoraCore/RedHat and FedoraCore/RedHat+Fedora.US.
In my understanding, for replacement packages the "leading 0" must match the FC/RH version the package is supposed to replace, while third party packages are supposed to use a custom %{disttag}, while leaving the rest of the Fedora.US release-tag intact.
That part I didn't understand. What is a "replacement package"?
Let's try to apply the GuideLines to an example: A package of mine requires perl-XML-LibXML-Common.
Neither Fedora Core 1 nor Fedora.US ship perl-XML-LibXML-Common, but Fedora Core 2 has it. There is a package proposal pending for months in Fedora.US's QA to add perl-XML-LibXML-Common to Fedora.US/FC1, but ATM it is not available for FC1.
Then review and approve Ville's package.
As I want to release my "pkg" for FC1 *now*, I'd have to release a perl-XML-LibXML-Common legacy package for FC1 *now*. However, I actually do not want to maintain a perl-XML-LibXML-Common myself and want the Fedora.US/FC1-Extras package to replace mine, once it will/should be released.
How to choose the "release-tag" for my "temporary legacy package", that an upgrade from FC1->FC2 will replace my perl-XML-LibXML-Common rpm with that shipped with FC2 and that a potential release of perl-XML-LibXML-Common by Fedora.US will replace my package?
Choose a %release lower than the current package in the queue and lower than the package in FC2:
perl-XML-LibXML-Common-0.13-0.fdr.4.ralf.1.1.rpm
Or choose the lowest %epoch:%version-%release possible. If you have doubts that 0.13-0 is enough, as a last resort you could even decrease %version to 0 and move the actual software version into the %release tag, e.g. perl-XML-LibXML-Common-0-0.13.1.ralf to indicate that this is temporary package only.
- FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm
- Thereofore I'd expect a potential FC1-Extras/Legacy package to be
named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.
Now, which release-tag to use for my "temporary legacy package"?
Dist-tags are evil. Attempts at defining inter-repository release-tags fail miserably as soon as multiple versions/releases of a package exist and contain different %release tags. Even if you put "ralf" at the very right, it would be included in EVR comparison and win over tags like "fdr" or "lvn", but also over numerical ones.
As it seems to me, the only functional solution for my purposes is: perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm
For example: perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm
Yes, just with 4, not 5.
On Wed, 2004-05-12 at 16:10, Michael Schwendt wrote:
On Wed, 12 May 2004 15:44:53 +0200, Ralf Corsepius wrote:
All I read on the "old Fedora Project" home page (http://www.fedora.us/wiki/PackageNamingGuidelines) is: ... C-4. Dist tag ... 0.fdr.%{X}.%{disttag} ...
AFAIS, this doesn't match with what Fedora.US currently ships:
It does.
Sorry, apparently I misread it.
It also does not seem to cover conventions on
- Replacement packages
Do you mean upgrades of what is included within Fedora Core?
Yes.
Obviously, %release must be higher than the current %release of the package in Fedora Core,
Not necessarily - E.g. I might want to apply patches or configure a package with different options etc.
- 3rd party add-on packages
both wrt. FedoraCore/RedHat and FedoraCore/RedHat+Fedora.US.
In my understanding, for replacement packages the "leading 0" must match the FC/RH version the package is supposed to replace,
Yes.
while third party packages are supposed to use a custom %{disttag}, while leaving the rest of the Fedora.US release-tag intact.
Yes.
That part I didn't understand. What is a "replacement package"?
Cf. above. I meant replacing a FC/RH or Fedora.US package with a 3rd party or local package.
Let's try to apply the GuideLines to an example: A package of mine requires perl-XML-LibXML-Common.
Neither Fedora Core 1 nor Fedora.US ship perl-XML-LibXML-Common, but Fedora Core 2 has it. There is a package proposal pending for months in Fedora.US's QA to add perl-XML-LibXML-Common to Fedora.US/FC1, but ATM it is not available for FC1.
Choose a %release lower than the current package in the queue and lower than the package in FC2:
That's not necessary:
# rpmver 0:0.13-0.fdr.5.ralf.1.1 0:0.13-5 0:0.13-5 is newer
=> FC1->FC2 upgrade will work.
# rpmver 0:0.13-0.fdr.5.ralf.1.1 0:0.13-0.fdr.5.1 0:0.13-0.fdr.5.1 is newer
=> An upgrade to a Fedora.US package will work.
perl-XML-LibXML-Common-0.13-0.fdr.4.ralf.1.1.rpm
Or choose the lowest %epoch:%version-%release possible. If you have doubts that 0.13-0 is enough, as a last resort you could even decrease %version to 0 and move the actual software version into the %release tag, e.g. perl-XML-LibXML-Common-0-0.13.1.ralf
This would contradict to the PackageGuideLines :)
- FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm
- Thereofore I'd expect a potential FC1-Extras/Legacy package to be
named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.
Now, which release-tag to use for my "temporary legacy package"?
Dist-tags are evil. Attempts at defining inter-repository release-tags fail miserably as soon as multiple versions/releases of a package exist and contain different %release tags.
This is only one side of the medal. On the other side dist-tags provide a clean separation for 3rd party supplied packages and prevents users from mixing up incompatible packages.
Even if you put "ralf" at the very right, it would be included in EVR comparison and win over tags like "fdr" or "lvn", but also over numerical ones.
As it seems to me, the only functional solution for my purposes is: perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm
For example: perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm
Yes, just with 4, not 5.
Cf. above.
Ralf
On Wed, 12 May 2004 18:09:03 +0200, Ralf Corsepius wrote:
It also does not seem to cover conventions on
- Replacement packages
Do you mean upgrades of what is included within Fedora Core?
Yes.
Updates for Fedora Core are not fedora.us' area. Except for the very few packages in the "patches" repository. But that one is a dead end. If something in Fedora Core is broken, it should be fixed in Fedora Core, not updated by a 3rd party repo. Replacements, i.e. substitutes for available functionality of packages in Fedora Core should be prepared as Fedora Alternatives.
Obviously, %release must be higher than the current %release of the package in Fedora Core,
Not necessarily - E.g. I might want to apply patches or configure a package with different options etc.
To maintain a clean install/update path in one direction (i.e. _to_ your packages), your packages must win EVR comparison. Downgrade back to original Core packages would be a special case (rpm -Uvh --oldpackage).
Let's try to apply the GuideLines to an example: A package of mine requires perl-XML-LibXML-Common.
Neither Fedora Core 1 nor Fedora.US ship perl-XML-LibXML-Common, but Fedora Core 2 has it. There is a package proposal pending for months in Fedora.US's QA to add perl-XML-LibXML-Common to Fedora.US/FC1, but ATM it is not available for FC1.
Choose a %release lower than the current package in the queue and lower than the package in FC2:
That's not necessary:
# rpmver 0:0.13-0.fdr.5.ralf.1.1 0:0.13-5 0:0.13-5 is newer
=> FC1->FC2 upgrade will work.
# rpmver 0:0.13-0.fdr.5.ralf.1.1 0:0.13-0.fdr.5.1 0:0.13-0.fdr.5.1 is newer
=> An upgrade to a Fedora.US package will work.
Well, that's just a side-effect of "ralf < 1".
perl-XML-LibXML-Common-0.13-0.fdr.4.ralf.1.1.rpm
Or choose the lowest %epoch:%version-%release possible. If you have doubts that 0.13-0 is enough, as a last resort you could even decrease %version to 0 and move the actual software version into the %release tag, e.g. perl-XML-LibXML-Common-0-0.13.1.ralf
This would contradict to the PackageGuideLines :)
Package naming guidelines are for fedora.us, not for indivual people's packages.
Now, which release-tag to use for my "temporary legacy package"?
Dist-tags are evil. Attempts at defining inter-repository release-tags fail miserably as soon as multiple versions/releases of a package exist and contain different %release tags.
This is only one side of the medal. On the other side dist-tags provide a clean separation for 3rd party supplied packages and prevents users from mixing up incompatible packages.
How that? repotags don't appear in dependencies.
On Wed, May 12, 2004 at 03:44:53PM +0200, Ralf Corsepius wrote:
The main idea is to have a scheme that does not apply to the scope of this one distribution and this current time window. It should apply on FC, RHL, RHEL and why not Mandrake/SuSE, whatever.
In an ideal world, yes.
But I have given in hope vendors can agree on a common naming scheme
Why? It hasn't even been proposed/tried, yet. And it is too early to propose it, but it can be taken account for to not blcok this path.
So the general stance is to have a suffux to the release tag containing an rpm-sortable disttag and an optional repotag, like
foo-1.2.3-4.rh9.ralf.src.rpm
AFAICT, this approach considers upgrades between distros, but it does not consider replacing RH supplied Core packages or nor replacing Fedora.US supplied packages nor does it consider replacing "local packages" with Fedora.US supplied packages.
I am not sure, what this means. The repotag can be used as an indicator about which packages in your system come from where (there are other ways apart from versioning/naming to achieve this).
If a repo choses to replace some part of the base distribution for some reason, it is in the responsibility of the repo to do so in a way as to not break anything and ensure future upgrade paths either by hierarchical build tags for automatically being replaced by newer vendor releases, or commitment to a community SLA.
A solution used by currently most free repos is to have "rh" for RHL and "rhfc" for FC.
Hmm? Fedora uses 0.fdr.<...>.1 , freshrpms used fr and now seems to have switched to using 'fc1.fr', you seem to be using rhfc, packman (No FC1 rpms there yet, but I am involved there) uses '<vendor-release>.pm', ... finally there are Ximian and JPackage ... and ...
most != all ;) Other than ATrpms rhfc1 is currently used by DAG, PlanetCCRMA, spc, dries, biorpms, and probably more.
- FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm
- Thereofore I'd expect a potential FC1-Extras/Legacy package to be
named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.
Now, which release-tag to use for my "temporary legacy package"?
As it seems to me, the only functional solution for my purposes is: perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm
For example: perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm
Is this a simple backport? For such packages I started to subtract 0.01 from the release to make me aware, that I changed almost nothing but add some BuildRequires, so I'd package the rebuild rpm as
perl-XML-LibXML-Common-0.13.0-4.99.rhfc1.ralf.src.rpm
:)
BTW that package already exists: # apt-cache policy perl-XML-LibXML-Common perl-XML-LibXML-Common: Installed: (none) Candidate: 0.13-2.rhfc1.dag Version Table: 0.13-2.rhfc1.dag 0 995 http://apt.sw.be redhat/fc1/en/i386/dag pkglist 0.13-1.rhfc1.dag 0 995 http://apt.sw.be redhat/fc1/en/i386/dag pkglist
On Wed, 2004-05-12 at 16:56, Axel Thimm wrote:
On Wed, May 12, 2004 at 03:44:53PM +0200, Ralf Corsepius wrote:
The main idea is to have a scheme that does not apply to the scope of this one distribution and this current time window. It should apply on FC, RHL, RHEL and why not Mandrake/SuSE, whatever.
In an ideal world, yes.
But I have given in hope vendors can agree on a common naming scheme
Why? It hasn't even been proposed/tried, yet. And it is too early to propose it, but it can be taken account for to not blcok this path.
So the general stance is to have a suffux to the release tag containing an rpm-sortable disttag and an optional repotag, like
foo-1.2.3-4.rh9.ralf.src.rpm
AFAICT, this approach considers upgrades between distros, but it does not consider replacing RH supplied Core packages or nor replacing Fedora.US supplied packages nor does it consider replacing "local packages" with Fedora.US supplied packages.
I am not sure, what this means. The repotag can be used as an indicator about which packages in your system come from where (there are other ways apart from versioning/naming to achieve this).
Exactly.
If a repo choses to replace some part of the base distribution for some reason, it is in the responsibility of the repo to do so in a way as to not break anything and ensure future upgrade paths either by hierarchical build tags for automatically being replaced by newer vendor releases, or commitment to a community SLA.
Exactly, that's what I am trying to achieve.
A solution used by currently most free repos is to have "rh" for RHL and "rhfc" for FC.
Hmm? Fedora uses 0.fdr.<...>.1 , freshrpms used fr and now seems to have switched to using 'fc1.fr', you seem to be using rhfc, packman (No FC1 rpms there yet, but I am involved there) uses '<vendor-release>.pm', ... finally there are Ximian and JPackage ... and ...
most != all ;) Other than ATrpms rhfc1 is currently used by DAG, PlanetCCRMA, spc, dries, biorpms, and probably more.
OK, ok, ... :-)
- FC2 ships perl-XML-LibXML-Common-0.13-5.i386.rpm
- Thereofore I'd expect a potential FC1-Extras/Legacy package to be
named perl-XML-LibXML-Common-0.13-0.fdr.5.1.i386.rpm.
Now, which release-tag to use for my "temporary legacy package"?
As it seems to me, the only functional solution for my purposes is: perl-XML-LibXML-Commmon-0.13-0.fdr.5.<char><*>.1.rpm
For example: perl-XML-LibXML-Common-0.13.0-0.fdr.5.ralf.1.1.rpm
Is this a simple backport?
It's even simpler: It is just a rebuilt FC2 package.
I.e. it would make the "classical case" of a Fedora.US Legacy package.
Michael's remark "sign Ville's proposal" however, makes me wonder if Red Hat and Fedora.US actually have an official policy on such packages.
His remark makes doubt it :(
BTW that package already exists: # apt-cache policy perl-XML-LibXML-Common perl-XML-LibXML-Common: Installed: (none) Candidate: 0.13-2.rhfc1.dag Version Table: 0.13-2.rhfc1.dag 0 995 http://apt.sw.be redhat/fc1/en/i386/dag pkglist 0.13-1.rhfc1.dag 0 995 http://apt.sw.be redhat/fc1/en/i386/dag pkglist
I am well aware perl-XML-LibXML-Common exists at various places (Even I have a local one), but ... it now is part of FC2 and there exists a proposal for Fedora.US/FC1 ...
Ralf
On May 12, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
So the general stance is to have a suffux to the release tag containing an rpm-sortable disttag and an optional repotag, like
foo-1.2.3-4.rh9.ralf.src.rpm
So the release tag looks like
<buildid><distid><distversion><repotag_opt>
where buildid shound end with digits (for example a simple integer like "3", or something conatining cvs info like "0.cvs20040512.16"), distid should be invariant for the family of distributions and distversion should be rpm-sortable (7.3, 8.0, 9 for instance). Repotag is placed at the least significant place wrt to rpm comparison and is optional.
Nobody objected this scheme above
I thought there was some minor opposition. <buildid> should *always* start with `0.', such that, whenever the distro contains the same version of the package, starting with 1 or above, the version in the distro is used. If you build multiple times, use 0.1, 0.2, etc.
My actual preference would be to instead use:
0.<distid><distversion><repotag_opt><buildid>
Conversely, all seem to be designed "to take over the system".
Even though this is our secret obsession, what do you man by that?
Dunno what he meant, but IMHO external repositories should be split into Extras and Alternatives, where Extras contain packages that add to the system without replacing any of its core components, leaving replacing/upgrading to Alternatives.
On Wed, May 12, 2004 at 08:01:24PM -0300, Alexandre Oliva wrote:
On May 12, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
So the release tag looks like
<buildid><distid><distversion><repotag_opt>
where buildid shound end with digits (for example a simple integer like "3", or something conatining cvs info like "0.cvs20040512.16"), distid should be invariant for the family of distributions and distversion should be rpm-sortable (7.3, 8.0, 9 for instance). Repotag is placed at the least significant place wrt to rpm comparison and is optional.
Nobody objected this scheme above
I thought there was some minor opposition. <buildid> should *always* start with `0.', such that, whenever the distro contains the same version of the package, starting with 1 or above, the version in the distro is used. If you build multiple times, use 0.1, 0.2, etc.
The scheme above abstracts hierarchical buildid into simply <buildid>. It was also proposed for Fedora Core packages, too, not only for 3rd party repos.
When we introduced the zero-prefix one and a half year ago, it was done in the assumption of a lack of communication with the higher hierarchy (the vendor).
IMHO in the Fedora context the communication is starting to become bilateral and such safeguards are less an issue. Packages proposed for submission from 3rd party repos into FC have been accompanied by a coordination of the 3rd party repo and the Red Hat insider ensuring proper upgrade paths (which is more than only the versioning).
My actual preference would be to instead use:
0.<distid><distversion><repotag_opt><buildid>
In hierarchical buildid the 0 is used when the version is higher than that of the vendor (or higher hierarchry). If the updated package is based on the same upstream version like the vendor's you need to use the vendor's buildid as the prefix.
Buildid at the least significant position? That would make it less important than the "random" repotag, e.g. the scheme above would be valid only within one repo and one dist.
Suppose you have
foo-1.2.3-4.rhfc1.blah.i386.rpm foo-1.2.3-4.rhfc2.blah.i386.rpm
A security errata lets you roll out
foo-1.2.3-5.rhfc1.blah.i386.rpm foo-1.2.3-5.rhfc2.blah.i386.rpm
In this scheme you know that both fc1 and fc2 will have the fixed version, even when the fc1 box decides to upgrade.
In the case of
foo-1.2.3-rhfc1.blah.4.i386.rpm foo-1.2.3-rhfc2.blah.4.i386.rpm
and
foo-1.2.3-rhfc1.blah.5.i386.rpm foo-1.2.3-rhfc2.blah.5.i386.rpm
The broken version of fc2 (4) will have a higher significance for rpm than the fixed for fc1 (5).
So the buildid (however composed, hierarchical or containing subverision information and so on) should be placed first in the release tag, the repotag last (as it should not be involved in comparisons) and the disttag can only be placed in the middle. ;)
Conversely, all seem to be designed "to take over the system".
Even though this is our secret obsession, what do you man by that?
Dunno what he meant, but IMHO external repositories should be split into Extras and Alternatives, where Extras contain packages that add to the system without replacing any of its core components, leaving replacing/upgrading to Alternatives.
I can only speak for the packages I have been upgrading, which are mostly upgraded for enabling other packages either in build dependencies (make, automake, autoconf) or in runtime dependencies. The consistent approach would be to pull packages depending on Alternatives into Alternatives themselves, so soon there would only be packages in Alternatives.
In general I don't see what purpose Alternatives would have. Users would have the (false) feeling of a more stable system by not using them, as no core packages have been replaced, but a couple of dozen kernel module rpms and daemons can destabilize and insecure your system far more than an updated package.
On May 12, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
My actual preference would be to instead use:
0.<distid><distversion><repotag_opt><buildid>
Buildid at the least significant position?
Doh, that was stupid, sorry. I keep forgetting the reason why it has to go before distid. Anyhow, I'd still strongly suggest it to start with for packages that are not in the Core. Use 0.<count> for <buildid> if you must, but don't start with 1 or higher unless you actually mean to update a package with such a buildid from the Core (or elsewhere).
In general I don't see what purpose Alternatives would have.
I can only speak for myself, but the reason I'd like to have separate Alternatives would be to enable myself to keep a rawhide install plus add-ons, such that, if some package from rawhide fails, I know the problem is in rawhide, not in an external repository that accidentally or intentionally brought in a different version of a library, program, whatever. I realize kernel modules are a trickier issue, but on a system meant to QA rawhide I wouldn't install them.
Another reason is that most repos lag behind rawhide. Just to give an example of one of my favorite pet peeves (without any offense to Dag intended), Dag's FC1 has a mozilla 1.6 build with a higher epoch than that of rawhide, even though his build is not actually more recent. However, when I run up2date -u, it won't ugprade because of epiphany's dependency on rawhide's mozilla, while dag's epiphany looks older than that in rawhide so up2date won't use it.
Sure enough, if the epoch wasn't higher than that of rawhide, I wouldn't run into this problem. It would be lovely if this could be fixed somehow, but there's no way for dag to downgrade the epoch without breaking his <= FC1 repos, and blizzard didn't think this was enough of a reason to bump up rawhide's mozilla epoch.
On Thu, May 13, 2004 at 02:54:11AM -0300, Alexandre Oliva wrote:
On May 12, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
In general I don't see what purpose Alternatives would have.
I can only speak for myself, but the reason I'd like to have separate Alternatives would be to enable myself to keep a rawhide install plus add-ons, such that, if some package from rawhide fails, I know the problem is in rawhide, not in an external repository that accidentally or intentionally brought in a different version of a library, program, whatever. I realize kernel modules are a trickier issue, but on a system meant to QA rawhide I wouldn't install them.
For QAing rawhide (or any other release) I would really not install anything but the object to QA. A lot of "non-Alternatives" are plugins that alter the functionality of the system. So reporting back, that rawhide has great mp3 playback in xmms will not help QA ;)
Another reason is that most repos lag behind rawhide. Just to give an example of one of my favorite pet peeves (without any offense to Dag intended), Dag's FC1 has a mozilla 1.6 build with a higher epoch than that of rawhide, even though his build is not actually more recent. However, when I run up2date -u, it won't ugprade because of epiphany's dependency on rawhide's mozilla, while dag's epiphany looks older than that in rawhide so up2date won't use it.
Sure enough, if the epoch wasn't higher than that of rawhide, I wouldn't run into this problem. It would be lovely if this could be fixed somehow, but there's no way for dag to downgrade the epoch without breaking his <= FC1 repos, and blizzard didn't think this was enough of a reason to bump up rawhide's mozilla epoch.
That was a packaging buglet, of the kind that hurts whereever it happens:
http://lists.atrpms.net/pipermail/repo-coord/2004-April/000240.html
I think Christopher would bump up and fix the epoch, if the other repos would promise not to continue epoch-inflation. :)
The problem there is less that of a missing Alternatives, but that of a lack of support of rawhide in most of the repos (until the last testing minutes ;).
You will find yourself in the same unpleasant situation if you were using Dag's galeon or something else that relies on say FC1's mozilla and could block upgrading to rawhide mozilla. Same for any library upgrade that bumbs up the major version in rawhide, but has 3rd party packages relying on the old version.
The way to attack these problems is to accept the fact that multiple incarnations of the same package should exist on a system (for packages that support this, like shared libraries). The current method of sometimes rebuilding compatibility packages is consuming too much time. Having packaging guidelines (like Mandrake/Debian for some areas) that allow concurrent use of different versions from the beginning will make mixing different ages of rawhide/FCN repos easier.
The drawback is that old libraries not used by anthing else anymore will sit and occupy space. These need to be identified and removed. There are already tools for identifying these packages and defining a "Provides: allow-multiple-versions" or "Provides: remove-if-no-reverse-dependencies" guideline would make this model waterproof.
While the first straightforward packages to dress that way would be shared libs, mozilla or gcc concurrent versions would also come to mind.
At the very least this solves more than Alternatives and is useful even in fedora core/rhel by itself for deploying new libraries w/o repackaging compatibility libs and re-QAing the "new" compatibility packages.
On Thu, May 13, 2004 at 02:54:11AM -0300, Alexandre Oliva wrote:
I can only speak for myself, but the reason I'd like to have separate Alternatives would be to enable myself to keep a rawhide install plus add-ons, such that, if some package from rawhide fails, I know the problem is in rawhide, not in an external repository that accidentally or intentionally brought in a different version of a library, program, whatever.
This sort of thing is where apt really shines. On my desktop systems, I like to be able to pull packages from freshrpms.net, since Matthias still has some packages that aren't available from fedora.us or livna.org. He has a lot of packages in common with fedora.us and livna.org though, so I use the following /etc/apt/preferences:
Package: * Pin: release c=os Pin-Priority: 992
Package: * Pin: release c=stable Pin-Priority: 991
("os" is Fedora Core stuff (apparently a lot of apt repositories are using "core" now), and "stable" is fedora.us/livna.org.)
With that, apt will prefer packages from Fedora Core over any of the other repositories, and fedora.us/livna.org packages over anything else.
I've been using this setup for quite a while now, and it works great. Now if only I could use apt on my x86-64 boxes... :-)
Steve
On May 13, 2004, Steven Pritchard steve@silug.org wrote:
This sort of thing is where apt really shines.
Yeah, pinning is the one feature from apt that I miss in up2date. But I don't use apt atm because some of the repos I use only have yum. Since up2date supports both apt and yum, that's what I use. But I get to live with the lack of pinning, for now :-/
On Thu, 2004-05-13 at 01:01, Alexandre Oliva wrote:
On May 12, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
So the general stance is to have a suffux to the release tag containing an rpm-sortable disttag and an optional repotag, like
foo-1.2.3-4.rh9.ralf.src.rpm
So the release tag looks like
<buildid><distid><distversion><repotag_opt>
where buildid shound end with digits (for example a simple integer like "3", or something conatining cvs info like "0.cvs20040512.16"), distid should be invariant for the family of distributions and distversion should be rpm-sortable (7.3, 8.0, 9 for instance). Repotag is placed at the least significant place wrt to rpm comparison and is optional.
Nobody objected this scheme above
I thought there was some minor opposition. <buildid> should *always* start with `0.', such that, whenever the distro contains the same version of the package, starting with 1 or above, the version in the distro is used. If you build multiple times, use 0.1, 0.2, etc.
My actual preference would be to instead use:
0.<distid><distversion><repotag_opt><buildid>Conversely, all seem to be designed "to take over the system".
Even though this is our secret obsession, what do you man by that?
Dunno what he meant,
I meant external repositories having chosen their release tags in such way, that they can not be upgraded to original RH or Fedora.US packages.
For example: Consider a package now being shipped by livna for legal issues: xxx-0.lvn.1.1.i386.rpm
Now suppose, the legal situation changes and the package shall be moved to Fedora.US: xxx-0.fdr.2.i386.rpm
# rpmver 0.fdr.2.1 0.lvn.1.1 0.lvn.1.1 is newer
=> Can't get rid of this lvn rpm by using Fedora.US PackageGuideLine conforming release tags, once you have installed it.
The same applies to other 3rd parties.
Another example: Axel ships perl-XML-Writer-0.4.6-7.rhfc1.at for FC1.
Now suppose, RH had chosen to ship perl-XML-Writer-0.4.6-1 with FC2 # rpmver 0.4.6-7.rhfc1.at 0.4.6-1 0.4.6-7.rhfc1.at is newer
=> An apt or yum based upgrade from FC1->FC2 will fail to pickup this FC2 package without Axel having any possibility to do anything about it.
Now consider my situation: In general, I want have a clean Fedora Core + Fedora Extras installation, but want to install packages which _currently_ are not part of Fedora Core1 nor Fedora Extra. Some of them (like the perl-XML-LibXML-Common rpm I had mentioned) are known to be part of FC2, others are likely to be part of future FC/FE release, others will probably be shipped by 3rd parties.
ATM, however I have to resort to locally built or non-FC/FE rpms, but do want to keep the possibility of FC and FE packages to replace my local packages during updates/upgrades.
but IMHO external repositories should be split into Extras and Alternatives, where Extras contain packages that add to the system without replacing any of its core components, leaving replacing/upgrading to Alternatives.
I am still missing an official RH or Fedora.US guide line.
What I see from experimenting with release tags yesterday, there implicitly exists such a convention:
<fc-release>.fdr.<fdr-release>.<local-vendor-id>.<local-release>.<disttag>
with: <fc-release> .. RH/FC package release number this package is supposed to be replace. 0 for Extras, equal to the RH/FC release number for Alternatives. <fdr-release> ... Fedora.US release number this package is supposed to replace. 0 if neither FC nor FE has this package. equal to FE's release number if FE has the packages. <local-vendor-id> ... an arbitrary string starting with a non-numeric character. <local-release> ... "Local Vendor's" actual build-number <disttag> ... Fedora US's disttag.
Some of the dots might be optional but didn't look into them (I like them :-) )
Ralf
On Thu, May 13, 2004 at 11:10:31AM +0200, Ralf Corsepius wrote:
On Thu, 2004-05-13 at 01:01, Alexandre Oliva wrote:
On May 12, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
Conversely, all seem to be designed "to take over the system".
Even though this is our secret obsession, what do you man by that?
Dunno what he meant,
I meant external repositories having chosen their release tags in such way, that they can not be upgraded to original RH or Fedora.US packages.
For example: Consider a package now being shipped by livna for legal issues: xxx-0.lvn.1.1.i386.rpm
Now suppose, the legal situation changes and the package shall be moved to Fedora.US: xxx-0.fdr.2.i386.rpm
# rpmver 0.fdr.2.1 0.lvn.1.1 0.lvn.1.1 is newer
=> Can't get rid of this lvn rpm by using Fedora.US PackageGuideLine conforming release tags, once you have installed it.
That's why the repotag needs to get moved to the back of the release tag. If it were
xxx-0.1.1.lvn.i386.rpm
then
xxx-0.2.fdr.i386.rpm
would have been OK.
The same applies to other 3rd parties.
Why? Almost all have the repotag at the end or missing.
Another example: Axel ships perl-XML-Writer-0.4.6-7.rhfc1.at for FC1.
Now suppose, RH had chosen to ship perl-XML-Writer-0.4.6-1 with FC2 # rpmver 0.4.6-7.rhfc1.at 0.4.6-1 0.4.6-7.rhfc1.at is newer
=> An apt or yum based upgrade from FC1->FC2 will fail to pickup this FC2 package without Axel having any possibility to do anything about it.
Axel could package perl-XML-Writer for FC2 for instance, or the person inside Red Hat should have picked a higher release number than already available. Which _is happening_, indeed!
After all this _is_ a community project, and Red Hat and 3rd parties are supposed to work together and not blindly package anymore. :) If you were to detect such an anomaly as above you should report it and either party can fix the issue. Nobody promised you no packaging bugs! :)
I am still missing an official RH or Fedora.US guide line.
There is an official Fedora.US guideline, you quoted it in previous mails :)
There is no official Red Hat guideline or no commitment to adopting all or parts of Fedora.US guidelines. I believe that the guidelines you are seeking are considered in draft mode. Since the completion of the merger between Red Hat's fedora and fedora.us requires a common guideline, this needs to be addressed before that, so it needs to get dealt with at some time.
Ralf, just go ahead and package in any scheme you now feel comfortable with, even if you later believe the scheme you chose was broken, you can still fix it. (Just don't use epoch inflation in any scheme!!! :)
Have fun packaging!
On May 13, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
=> An apt or yum based upgrade from FC1->FC2 will fail to pickup this FC2 package without Axel having any possibility to do anything about it.
Axel could package perl-XML-Writer for FC2 for instance, or the person inside Red Hat should have picked a higher release number than already available. Which _is happening_, indeed!
But a Fedora Core packager can't possibly monitor every single RPM repository in existence. Sure s/he can monitor the major ones, but that doesn't cover, for example, private repos that aren't available outside. The packaging guidelines are useful for such private repos as well, such that private packages. And if it's good for private repos in the sense of getting a clear upgrade path, it's good for public repos in the this sense as well.
Using 0.<buildnumber> for Extras-like packages is a very simple way to ensure that, if the package ever makes it to the Core, there will be a clear upgrade path.
On Thu, May 13, 2004 at 04:02:11PM -0300, Alexandre Oliva wrote:
On May 13, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
=> An apt or yum based upgrade from FC1->FC2 will fail to pickup this FC2 package without Axel having any possibility to do anything about it.
Axel could package perl-XML-Writer for FC2 for instance, or the person inside Red Hat should have picked a higher release number than already available. Which _is happening_, indeed!
But a Fedora Core packager can't possibly monitor every single RPM repository in existence. Sure s/he can monitor the major ones, but that doesn't cover, for example, private repos that aren't available outside.
Certainly, and the hierarchy buildid method should be applied by private repos for their own sake. OTOH private rpms do not exist in the common name- and version space, so private repos can do as they please, for any purpose of theirs.
The packaging guidelines are useful for such private repos as well, such that private packages. And if it's good for private repos in the sense of getting a clear upgrade path, it's good for public repos in the this sense as well.
And consequently good for Red Hat's own packages themselves. ;)
No packaging policy will have a real chance if the major part of packages, the ones from the base don't follow it. Even a suboptimal policy chosen by RH would be better than the current situation.
More than the 0-prefix which RH as the first tier hierarchy would not need, the disttag issue should be addressed and finally brought to an end (the discussion is more than half a year old). So my suggestion would be for Red Hat to choose the names of the disttags. Anything that starts with letters and rpm sorts safely RHL and FC release lines, like
rhl7.3 < rhl8.0 < rhl9 < tfp1 < tfp2 ("the fedora project") fp0.7.3 < fp0.8.0 < fp0.9 < fp1 < fp2 rh7.3 < rh8.0 < rh9 < rhfc1 < rhfc2
(and el3 or rhel3 for the RHEL family, the RHEL family should not rpm-sort with the above, as there are no officially supported upgrade paths RHEL <-> FC).
Yes, I know some people do not like the connotation "rh" to "fc", but the above is a technical solution. Let Red Hat just set the disttags to any working set (both technically and politically) and the repos will adopt it immediately, I am sure.
So will FC3 has disttags? :)
On May 13, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
So will FC3 has disttags? :)
Frankly, I don't see the point of disttags for the core packages. The only purpose of disttags IMHO is to differentiate builds of the very same package for different OSs/releases. Fedora Core packages never use this; if there's a rebuild for the next release of Fedora Core, the build number is incremented. If there's an errata-like patch build for an update for an earlier release, it can get a .1 suffix to the released build number, for the first such build, and have this suffix incremented for subsequent builds. So, when are they useful for packages in the Core?
On Thu, May 13, 2004 at 09:28:00PM +0200, Axel Thimm wrote:
On Thu, May 13, 2004 at 04:02:11PM -0300, Alexandre Oliva wrote:
The packaging guidelines are useful for such private repos as well, such that private packages. And if it's good for private repos in the sense of getting a clear upgrade path, it's good for public repos in the this sense as well.
And consequently good for Red Hat's own packages themselves. ;) [...] So will FC3 has disttags? :)
On Fri, May 14, 2004 at 01:51:56AM -0300, Alexandre Oliva wrote:
Frankly, I don't see the point of disttags for the core packages. The only purpose of disttags IMHO is to differentiate builds of the very same package for different OSs/releases. Fedora Core packages never use this; if there's a rebuild for the next release of Fedora Core, the build number is incremented. If there's an errata-like patch build for an update for an earlier release, it can get a .1 suffix to the released build number, for the first such build, and have this suffix incremented for subsequent builds. So, when are they useful for packages in the Core?
o for first it will certainly not hurt at all. o it will enable the cousing fedoralegacy to have clean backbuilds. o it will enable Red Hat to have decent common errata for multiple non-EOLed releases. o it will enable rawhide to have good upgrade paths for unchanged packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all packages for test2. o it will provide a coherent specification for Red Hat and third party repos to use. Asking of repos to change/apply vereioning specs w/o Red Hat to follow is not going to work. o there will be no more big threads about disttags w/o a resolution :)
The downside is that someone must spent a day and a half to get the build system at Red Hat to add disttags.
Disttags are a good concept. The only thing hindering them in the Fedora/RHEL world is the choice for a specific implementation. If the vendor does not go along, you will continue to have anarchy in guidelines.
On May 14, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
On Thu, May 13, 2004 at 09:28:00PM +0200, Axel Thimm wrote:
On Fri, May 14, 2004 at 01:51:56AM -0300, Alexandre Oliva wrote:
Frankly, I don't see the point of disttags for the core packages. [...] when are they useful for packages in the Core?
o for first it will certainly not hurt at all. o it will enable the cousing fedoralegacy to have clean backbuilds. o it will enable Red Hat to have decent common errata for multiple non-EOLed releases. o it will enable rawhide to have good upgrade paths for unchanged packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all packages for test2. o it will provide a coherent specification for Red Hat and third party repos to use. Asking of repos to change/apply vereioning specs w/o Red Hat to follow is not going to work. o there will be no more big threads about disttags w/o a resolution :)
You seem to have good points. I'm convinced. Unfortunately, I have no say on what happens to Fedora Core packages, other than what I talk developers into doing by filing bug reports in bugzilla :-)
On Fri, 2004-05-14 at 08:57, Axel Thimm wrote:
On Thu, May 13, 2004 at 09:28:00PM +0200, Axel Thimm wrote:
On Thu, May 13, 2004 at 04:02:11PM -0300, Alexandre Oliva wrote:
The packaging guidelines are useful for such private repos as well, such that private packages. And if it's good for private repos in the sense of getting a clear upgrade path, it's good for public repos in the this sense as well.
And consequently good for Red Hat's own packages themselves. ;) [...] So will FC3 has disttags? :)
On Fri, May 14, 2004 at 01:51:56AM -0300, Alexandre Oliva wrote:
Frankly, I don't see the point of disttags for the core packages. The only purpose of disttags IMHO is to differentiate builds of the very same package for different OSs/releases. Fedora Core packages never use this; if there's a rebuild for the next release of Fedora Core, the build number is incremented. If there's an errata-like patch build for an update for an earlier release, it can get a .1 suffix to the released build number, for the first such build, and have this suffix incremented for subsequent builds. So, when are they useful for packages in the Core?
o for first it will certainly not hurt at all.
It hurts in the eyes ;-)
o it will enable the cousing fedoralegacy to have clean backbuilds.
I'm not sure if I understand you correctly (what is "cousing"?), but you can simply do the obvious and append the release to the existing one, like in:
last rel: "3", next rel: "3.1"
or for the sake of being talkative to users maybe even:
last rel: "3", next rel: "3.fc1.1"
despite that being ugly to the eye. But we would have to support FC1 only for a short time after FC2 is out, don't we? In that case, even I can live with a certain amount of ugliness.
o it will enable Red Hat to have decent common errata for multiple non-EOLed releases.
How do we not have that today?
o it will enable rawhide to have good upgrade paths for unchanged packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all packages for test2.
As long as either the release itself or one component is an integer, bumping that is easy. In fact it works today, ask Elliot -- I don't think he fiddles manually with hundreds of release tags when doing a mass-rebuild.
o it will provide a coherent specification for Red Hat and third party repos to use. Asking of repos to change/apply vereioning specs w/o Red Hat to follow is not going to work.
I think we're talking about Fedora Core and 3rd party repos, let's make that distinction even if Fedora Core development is largely staffed with Red Hat people today. My impression is that Fedora Core objectives in this issue are to work inside of Core/Extras/Alternatives however these are defined, anything beyond is "out of scope". That's my personal opinion.
o there will be no more big threads about disttags w/o a resolution :)
Haha. On the other hand, we could all just shut up ;-).
The downside is that someone must spent a day and a half to get the build system at Red Hat to add disttags.
Obviously you are joking, but then you haven't seen our build system yet, have you?
Disttags are a good concept. The only thing hindering them in the Fedora/RHEL world is the choice for a specific implementation. If the vendor does not go along, you will continue to have anarchy in guidelines.
In my point of view, disttags serve only one purpose, namely differentiating from which repository a package comes in the file name, at the price of looking ugly. They do not improve interoperability a bit because the package manager wouldn't know that if package "foo" from repo "bar" needs "baz" then it must come from "bar" as well or at least from "stfu" ;-). Using disttags doesn't make upgrading package "xyz" from the external repo "abc" to the one in Core easier unless both sides plan in that regard.
If I were to "usurp" a package for Core, I would only want to ensure upgradability for that package eventually existing in Extras, for which simple integers as releases suffice, mind my words (incrementing them is an easy operation ;-) or alternatively for the package from another repo I based off. I would not try to be "later" v-r-wise than any other instance of the package in one of your, Dag's or any other of the myriads of repositories because things would then simply be getting out of hand.
Nils
On Fri, May 14, 2004 at 10:42:18AM +0200, Nils Philippsen wrote:
On Fri, 2004-05-14 at 08:57, Axel Thimm wrote:
o it will enable the cousing fedoralegacy to have clean backbuilds.
I'm not sure if I understand you correctly (what is "cousing"?),
sorry, that's a typo it's "cousin".
but you can simply do the obvious and append the release to the existing one, like in:
last rel: "3", next rel: "3.1"
or for the sake of being talkative to users maybe even:
last rel: "3", next rel: "3.fc1.1"
But these _are_ disttags! :)
o it will enable Red Hat to have decent common errata for multiple non-EOLed releases.
How do we not have that today?
Don't ask me, have a look at the differnt (read per package) solutions used at Red Hat/Fedora Core for common errata (e.g. kernel, glibc, ethereal). Some packages got a ".7", ".8", ".9" appended, others an "FC1" etc, even others simply enumerated them.
If there were policy, you could use foo-1.2.3-4.fc1.i386.rpm and foo-1.2.3-4.fc2.i386.rpm for pushing out common errata for FC1 and FC2, w/o reinventing the wheel each time.
o it will enable rawhide to have good upgrade paths for unchanged packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all packages for test2.
As long as either the release itself or one component is an integer, bumping that is easy. In fact it works today, ask Elliot -- I don't think he fiddles manually with hundreds of release tags when doing a mass-rebuild.
No, that would be suicide, but the bumbed Release tag is not helpful for investigating what has changed. Sometime the %changelog is helpful, other times one need to open the packages and compare content. A changing disttag with otherwise invariant buildid doesn't even need a changelog about rebuilding.
o it will provide a coherent specification for Red Hat and third party repos to use. Asking of repos to change/apply vereioning specs w/o Red Hat to follow is not going to work.
I think we're talking about Fedora Core and 3rd party repos, let's make that distinction even if Fedora Core development is largely staffed with Red Hat people today. My impression is that Fedora Core objectives in this issue are to work inside of Core/Extras/Alternatives however these are defined, anything beyond is "out of scope". That's my personal opinion.
Well, the thread started about someone wanting to provide packages for third party repos or Extras with disttags. If you look at fedora.us, which is deemed ti become Fedora Extras, you will see disttags. Are you suggesting to remove them? fedora.us developers would not be happy about that.
The downside is that someone must spent a day and a half to get the build system at Red Hat to add disttags.
Obviously you are joking, but then you haven't seen our build system yet, have you?
Of course, I am joking. OTOH there are existing buildsystems in various projects including ATrpms, fedora.us, Dag and probably more that have solved this a long time since. So it is not really rocket science, once a disttag scheme has been approved. Perhaps you should hire me ;)
Disttags are a good concept. The only thing hindering them in the Fedora/RHEL world is the choice for a specific implementation. If the vendor does not go along, you will continue to have anarchy in guidelines.
In my point of view, disttags serve only one purpose, namely differentiating from which repository a package comes in the file name, at the price of looking ugly.
Oops, I understand that we are probably talking about different things. What you are thinking of are "repotags" like "fr", "at", "dag", "ccrma", "spc", "dries" that only serve for uglyness and have no functionality. I am not promoting their use, they shoudl be considered optional and should stay out of our way (in an upgrade path consideration, e.g. shove them at the very end of the release tag if you really must so).
If I were to "usurp" a package for Core, I would only want to ensure upgradability for that package eventually existing in Extras, for which simple integers as releases suffice, [...]
You should think outside of the Fedora Core scope where disttags are indeed only useful for common errata with simultaneous non-EOLed releases.
Projects very near to Fedora Core (not "3rd party") like Fedora Extras predecessor fedora.us, and fedoralegacy.org do require more often to have common builds differentiating in the release built against. So disttags are required.
And as a community project you cannot keep out of scope "3rd party" repos. They also support multiple releases of Red Hat and Fedora and ths need disttags (not repotags!).
And really, disttags do not hurt at all. Aesthetics don't count in packaging, otherwise we would package foo-1.2.3-4.el3.at.i386.rpm into setup.exe.
On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:
but you can simply do the obvious and append the release to the existing one, like in:
last rel: "3", next rel: "3.1"
or for the sake of being talkative to users maybe even:
last rel: "3", next rel: "3.fc1.1"
But these _are_ disttags! :)
Still ugly, but I admit that packagers using them should use the same hwen referring to the same distro-version.
o it will enable Red Hat to have decent common errata for multiple non-EOLed releases.
How do we not have that today?
Don't ask me, have a look at the differnt (read per package) solutions used at Red Hat/Fedora Core for common errata (e.g. kernel, glibc, ethereal). Some packages got a ".7", ".8", ".9" appended, others an "FC1" etc, even others simply enumerated them.
I meant that whatever the release tags of the packages are is in no way relevant to the errata package being decent or not. As I mentioned in my last mail, I can suffer a little ugliness but be that as it may, packages will work (or not) regardless of how shrewdly we build our release tags or not, as long as v-r is rising strictly monotonously for RPM.
If there were policy, you could use foo-1.2.3-4.fc1.i386.rpm and foo-1.2.3-4.fc2.i386.rpm for pushing out common errata for FC1 and FC2, w/o reinventing the wheel each time.
I wouldn't put "incrementing a number" in the vicinity of anything "invention", look at the USPTO where this got us ;-).
o it will enable rawhide to have good upgrade paths for unchanged packages, e.g. bump the disttag from fc1.90 to fc1.91 to rebuild all packages for test2.
As long as either the release itself or one component is an integer, bumping that is easy. In fact it works today, ask Elliot -- I don't think he fiddles manually with hundreds of release tags when doing a mass-rebuild.
No, that would be suicide, but the bumbed Release tag is not helpful for investigating what has changed. Sometime the %changelog is helpful, other times one need to open the packages and compare content. A changing disttag with otherwise invariant buildid doesn't even need a changelog about rebuilding.
Nah. I don't want the release tag to be meaningful at all, that's what changelog is for. By codifying disttags into release, you practically limit yourself to rebuild only when the distro-version changes and believe me, we build more often and for much more purposes than only this.
o it will provide a coherent specification for Red Hat and third party repos to use. Asking of repos to change/apply vereioning specs w/o Red Hat to follow is not going to work.
I think we're talking about Fedora Core and 3rd party repos, let's make that distinction even if Fedora Core development is largely staffed with Red Hat people today. My impression is that Fedora Core objectives in this issue are to work inside of Core/Extras/Alternatives however these are defined, anything beyond is "out of scope". That's my personal opinion.
Well, the thread started about someone wanting to provide packages for third party repos or Extras with disttags. If you look at fedora.us, which is deemed ti become Fedora Extras, you will see disttags. Are you suggesting to remove them? fedora.us developers would not be happy about that.
I would leave disttags to the package maintainers discretion, perhaps within certain limits imposed by the build system.
The downside is that someone must spent a day and a half to get the build system at Red Hat to add disttags.
Obviously you are joking, but then you haven't seen our build system yet, have you?
Of course, I am joking. OTOH there are existing buildsystems in various projects including ATrpms, fedora.us, Dag and probably more that have solved this a long time since. So it is not really rocket science, once a disttag scheme has been approved. Perhaps you should hire me ;)
You wouldn't be content with what I can offer you as a salary (speaking strictly as a private person) ;-).
Disttags are a good concept. The only thing hindering them in the Fedora/RHEL world is the choice for a specific implementation. If the vendor does not go along, you will continue to have anarchy in guidelines.
In my point of view, disttags serve only one purpose, namely differentiating from which repository a package comes in the file name, at the price of looking ugly.
Oops, I understand that we are probably talking about different things. What you are thinking of are "repotags" like "fr", "at", "dag", "ccrma", "spc", "dries" that only serve for uglyness and have no functionality. I am not promoting their use, they shoudl be considered optional and should stay out of our way (in an upgrade path consideration, e.g. shove them at the very end of the release tag if you really must so).
Understood.
If I were to "usurp" a package for Core, I would only want to ensure upgradability for that package eventually existing in Extras, for which simple integers as releases suffice, [...]
You should think outside of the Fedora Core scope where disttags are indeed only useful for common errata with simultaneous non-EOLed releases.
Projects very near to Fedora Core (not "3rd party") like Fedora Extras predecessor fedora.us, and fedoralegacy.org do require more often to have common builds differentiating in the release built against. So disttags are required.
Not necessarily. When discussing build systems, more than once the idea popped up that the maintainer shouldn't care about the release and that it would be autogenerated. These kind of build systems would be fed from a revision control system where you would put different distro-versions into different branches. How the build system generates release tags from that is a matter of discussion, but nothing the package maintainer should have to care for then.
And as a community project you cannot keep out of scope "3rd party" repos. They also support multiple releases of Red Hat and Fedora and ths need disttags (not repotags!).
Not in my opinion.
And really, disttags do not hurt at all. Aesthetics don't count in packaging, otherwise we would package foo-1.2.3-4.el3.at.i386.rpm into setup.exe.
Replacing ugliness with abomination here ;-)?
Nils
On Fri, May 14, 2004 at 01:37:45PM +0200, Nils Philippsen wrote:
Projects very near to Fedora Core (not "3rd party") like Fedora Extras predecessor fedora.us, and fedoralegacy.org do require more often to have common builds differentiating in the release built against. So disttags are required.
Not necessarily. When discussing build systems, more than once the idea popped up that the maintainer shouldn't care about the release and that it would be autogenerated. These kind of build systems would be fed from a revision control system where you would put different distro-versions into different branches. How the build system generates release tags from that is a matter of discussion, but nothing the package maintainer should have to care for then.
Hm, I'd argue that the release tag is often quite important (the buildid before the disttag), because it can be referred to from other package in dependencies. E.g. when you move a file from one package to another or have any special new releationship between packages than need to Conflict/Require something based on the release tag.
That's another point where disttags are useful. If you fix your package foo to foo-1.2.3-5.fc1 and foo-1.2.3-5.fc2, you can safely use only
# foo up to 1.2.3-4 was buggy Requires: foo >= 1.2.3-5
without mentining any disttags in the packages bar-6.7.8-9.fc1 and bar-6.7.8-9.fc2, e.g. the disttag does not have to be mentioned in dependencies. A scheme with manual coding of upgrade paths would require different specfiles for bar-6.7.8-9.fc1 and bar-6.7.8-9.fc2 as the dependencies would have to written differently.
What the buildsystem should do is add the disttags as suffixes to the resulting rpm, so developers/packagers still only have to think about the buildid and not the rest.
E.g. specfiles and src.rpm could stay as is in rawhide, the buildsystem would adorne the release suffix as needed.
Later fedoralegacy in need for a security update can simply rebuild the same package with the same buildid/specfile/src.rpm, but the buildsystem would automatically have placed that package in a proper upgrade path for future upgrading of the fedoralegacy build.
For example FC1 goes EOL and foo-1.2.3 has a security issue. FC3 has foo-2.3.4-5 as foo-2.3.4-5.src.rpm and foo-2.3.4-5.fc3.i386.rpm. A fedoralegacy packager tests whether the src.rpm rebuilds and works as is on FC1, and if yes, simply pulls in the same source package, which will yield foo-2.3.4-5.fc1.i386.rpm in fedoralegacy (or perhaps fedoralegacy also uses a repotag id and this becomes foo-2.3.4-5.fc1.lgcy.i386.rpm).
This minimizes maintainance of multiple releases at the cost of a some little aesthetics.
(and to be honest all people are using repos like fedora.us, freshrpms, ATrpms etc., each of which has its own interpretation of the disharmonizing art of package naming and versioning obfuscation, so users are hardened ;)
And as a community project you cannot keep out of scope "3rd party" repos. They also support multiple releases of Red Hat and Fedora and ths need disttags (not repotags!).
Not in my opinion.
What? Fedora is not a community project or 3rd party repos are not within the community? :)
And really, disttags do not hurt at all. Aesthetics don't count in packaging, otherwise we would package foo-1.2.3-4.el3.at.i386.rpm into setup.exe.
Replacing ugliness with abomination here ;-)?
No, it is a psychological trick: After being shocked by uttermost disgust disttags should look nicer, don't they? ;)
On Fri, 2004-05-14 at 14:19, Axel Thimm wrote:
On Fri, May 14, 2004 at 01:37:45PM +0200, Nils Philippsen wrote:
Projects very near to Fedora Core (not "3rd party") like Fedora Extras predecessor fedora.us, and fedoralegacy.org do require more often to have common builds differentiating in the release built against. So disttags are required.
Not necessarily. When discussing build systems, more than once the idea popped up that the maintainer shouldn't care about the release and that it would be autogenerated. These kind of build systems would be fed from a revision control system where you would put different distro-versions into different branches. How the build system generates release tags from that is a matter of discussion, but nothing the package maintainer should have to care for then.
Hm, I'd argue that the release tag is often quite important (the buildid before the disttag), because it can be referred to from other package in dependencies. E.g. when you move a file from one package to another or have any special new releationship between packages than need to Conflict/Require something based on the release tag.
You can always use the releasetag generated by the build system for this.
That's another point where disttags are useful. If you fix your package foo to foo-1.2.3-5.fc1 and foo-1.2.3-5.fc2, you can safely use only
# foo up to 1.2.3-4 was buggy Requires: foo >= 1.2.3-5
without mentining any disttags in the packages bar-6.7.8-9.fc1 and bar-6.7.8-9.fc2, e.g. the disttag does not have to be mentioned in dependencies. A scheme with manual coding of upgrade paths would require different specfiles for bar-6.7.8-9.fc1 and bar-6.7.8-9.fc2 as the dependencies would have to written differently.
Agreed, but this is only true in the special case where you use the same version/release across all dists.
Nils
On Fri, May 14, 2004 at 06:47:13PM +0200, Nils Philippsen wrote:
On Fri, 2004-05-14 at 14:19, Axel Thimm wrote:
On Fri, May 14, 2004 at 01:37:45PM +0200, Nils Philippsen wrote:
Projects very near to Fedora Core (not "3rd party") like Fedora Extras predecessor fedora.us, and fedoralegacy.org do require more often to have common builds differentiating in the release built against. So disttags are required.
Not necessarily. When discussing build systems, more than once the idea popped up that the maintainer shouldn't care about the release and that it would be autogenerated. These kind of build systems would be fed from a revision control system where you would put different distro-versions into different branches. How the build system generates release tags from that is a matter of discussion, but nothing the package maintainer should have to care for then.
Hm, I'd argue that the release tag is often quite important (the buildid before the disttag), because it can be referred to from other package in dependencies. E.g. when you move a file from one package to another or have any special new releationship between packages than need to Conflict/Require something based on the release tag.
You can always use the releasetag generated by the build system for this.
If it is coming from an SCM and is immediatly retrievable, it's OK. If you had to wait for a rawhide build to see your release tag to use in further dependencies that would be less useful.
That's another point where disttags are useful. If you fix your package foo to foo-1.2.3-5.fc1 and foo-1.2.3-5.fc2, you can safely use only
# foo up to 1.2.3-4 was buggy Requires: foo >= 1.2.3-5
without mentining any disttags in the packages bar-6.7.8-9.fc1 and bar-6.7.8-9.fc2, e.g. the disttag does not have to be mentioned in dependencies. A scheme with manual coding of upgrade paths would require different specfiles for bar-6.7.8-9.fc1 and bar-6.7.8-9.fc2 as the dependencies would have to written differently.
Agreed, but this is only true in the special case where you use the same version/release across all dists.
That's exactly what disttags are good for. And it is not a too special case outside of Red Hat. Almost all 3rd party repos support more than one release and package the same upstream version/same patches multiple times. The closest examples are fedora.us and fedoralegacy. Both these projects and the rest of the repos would benefit greatly from a canonical introduction of disttags.
And there is no drawback (aesthetics put aside, but we have already lost the beauty price, so let's try for the technology award ;).
On Fri, 2004-05-14 at 13:37, Nils Philippsen wrote:
On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:
Projects very near to Fedora Core (not "3rd party") like Fedora Extras predecessor fedora.us, and fedoralegacy.org do require more often to have common builds differentiating in the release built against. So disttags are required.
Not necessarily. When discussing build systems, more than once the idea popped up that the maintainer shouldn't care about the release and that it would be autogenerated. These kind of build systems would be fed from a revision control system where you would put different distro-versions into different branches. How the build system generates release tags from that is a matter of discussion, but nothing the package maintainer should have to care for then.
Fully agreed.
And as a community project you cannot keep out of scope "3rd party" repos. They also support multiple releases of Red Hat and Fedora and ths need disttags (not repotags!).
Not in my opinion.
Neither in mine. IMO, what some people on this thread call "disttag" actually is the "root distribution's" repotag. What is confusing is the fact that RH/FC doesn't use an explicit "RH-repotag/disttag", while 3rd party packagers apply different and partially contradicting "disttag" conventions.
Having this in mind, I also think, what 3rd party packagers actually need is a path into a tree of package sets originating from different repositories, e.g.:
Fedora Core | +-> Fedora Extras -> Local FC+FE Add Ons +-> ATrpms -> Local FC+ATrpms Add Ons +-> ....
IMO, the actual questions are: Is there a need to encode these paths into rpms and if yes how? IMO, yes, there is a need to encode these paths.
Ralf
On Mon, May 17, 2004 at 07:16:14AM +0200, Ralf Corsepius wrote:
On Fri, 2004-05-14 at 13:37, Nils Philippsen wrote:
On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:
And as a community project you cannot keep out of scope "3rd party" repos. They also support multiple releases of Red Hat and Fedora and ths need disttags (not repotags!).
Not in my opinion.
Neither in mine. IMO, what some people on this thread call "disttag" actually is the "root distribution's" repotag. What is confusing is the fact that RH/FC doesn't use an explicit "RH-repotag/disttag", while 3rd party packagers apply different and partially contradicting "disttag" conventions.
No, please don't add to this confusion by defining disttags to be repotags of some kind.
For simplicity's sake forget about repotag, their current usage/existance etc. The repotag serves no real technical functionality.
The disttag OTOH is the tools for automatically maintaining upgrade paths even when building from the same specfile into multiple different distributions.
E.g. you build foo against FC1's and FC2's glibc and want to build from FC1 to be rpm-older than the one from FC2.
You achive this by either carefully choosing release tags (say "3" for FC1, "4" for FC2) which leads to different specfiles/src.rpm etc., and non-predictable release tags ("which one fixed the xyz issue? Release 3 or 4?").
Or you pick the same release tag (for example "3") and add a different suffix that will always be rpm-less for FC1 than for FC2 like "fc1" and "fc2". The packages are now called foo-1.2-3.fc1 and foo-1.2-3.fc2 and you know that the true buildid is the "3" which can be used in ranged dependencies (Requires: foo >= 1.2-3). And the upgrade paths are always pertained.
Having this in mind, I also think, what 3rd party packagers actually need is a path into a tree of package sets originating from different repositories, e.g.:
Fedora Core | +-> Fedora Extras -> Local FC+FE Add Ons +-> ATrpms -> Local FC+ATrpms Add Ons +-> ....
IMO, the actual questions are: Is there a need to encode these paths into rpms and if yes how? IMO, yes, there is a need to encode these paths.
The above quote is about repotags, don't confuse them with disttags. And no, repotags are not really needed. Some users think it is better/easier for identifying package origin, some packagers need them for their vanity. ;)
On Mon, 2004-05-17 at 20:26, Axel Thimm wrote:
On Mon, May 17, 2004 at 07:16:14AM +0200, Ralf Corsepius wrote:
On Fri, 2004-05-14 at 13:37, Nils Philippsen wrote:
On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:
And as a community project you cannot keep out of scope "3rd party" repos. They also support multiple releases of Red Hat and Fedora and ths need disttags (not repotags!).
Not in my opinion.
Neither in mine. IMO, what some people on this thread call "disttag" actually is the "root distribution's" repotag. What is confusing is the fact that RH/FC doesn't use an explicit "RH-repotag/disttag", while 3rd party packagers apply different and partially contradicting "disttag" conventions.
No, please don't add to this confusion by defining disttags to be repotags of some kind.
For simplicity's sake forget about repotag, their current usage/existance etc. The repotag serves no real technical functionality.
To reiterate: I think distinguishing between "disttags" and "repotags" is meaningless, it's all about repotags, only.
In my understanding "disttags" actually are a special case of repotags: The repotag of the "root" of the repository hierarchy your packages are using.
The disttag OTOH is the tools for automatically maintaining upgrade paths even when building from the same specfile into multiple different distributions.
This does not contradict to what I wrote above.
You achive this by either carefully choosing release tags (say "3" for FC1, "4" for FC2) which leads to different specfiles/src.rpm etc., and non-predictable release tags ("which one fixed the xyz issue? Release 3 or 4?").
Or you pick the same release tag (for example "3") and add a different suffix that will always be rpm-less for FC1 than for FC2 like "fc1" and "fc2". The packages are now called foo-1.2-3.fc1 and foo-1.2-3.fc2 and you know that the true buildid is the "3" which can be used in ranged dependencies (Requires: foo >= 1.2-3). And the upgrade paths are always pertained.
OK, an example of how I see it:
Consider you are building add-on packages to Fedora Core N
Dependency tree: FCN -> AddOns
Fedora Core N repotag: fcN. Add On repotag: AddOn.
A convention on release tags could be: <repotag><number>
This would result into a release tag similar to this: fcN.<fcN-id>.AddOn.<AddOn-id>
What might confuse you is me regarding "fcN" as "repotag" and not "fc" as you seem to be seeing it.
Another part of confusion might stem from RH/FC currently not using any repotag/disttag (which could be interpreted as "empty") and Fedora.US trying to add one.
Ralf
On Tue, May 18, 2004 at 06:28:17AM +0200, Ralf Corsepius wrote:
On Mon, 2004-05-17 at 20:26, Axel Thimm wrote:
On Mon, May 17, 2004 at 07:16:14AM +0200, Ralf Corsepius wrote:
On Fri, 2004-05-14 at 13:37, Nils Philippsen wrote:
On Fri, 2004-05-14 at 11:07, Axel Thimm wrote:
And as a community project you cannot keep out of scope "3rd party" repos. They also support multiple releases of Red Hat and Fedora and ths need disttags (not repotags!).
Not in my opinion.
Neither in mine. IMO, what some people on this thread call "disttag" actually is the "root distribution's" repotag. What is confusing is the fact that RH/FC doesn't use an explicit "RH-repotag/disttag", while 3rd party packagers apply different and partially contradicting "disttag" conventions.
No, please don't add to this confusion by defining disttags to be repotags of some kind.
For simplicity's sake forget about repotag, their current usage/existance etc. The repotag serves no real technical functionality.
To reiterate: I think distinguishing between "disttags" and "repotags" is meaningless, it's all about repotags, only.
Well, what you define as a repotag is what the rest of us call a disttag. Please use the nomenclature common on this list. Possible disttags are fc1, fc2, el3 etc., they are an abbreviated rpm-sortable id for a release (sortable within a distribution family, like FC vs RHEL) ensuring proper upgrade paths as discussed in this thread.
(optional!) repotags are "fr", "ccrma", "at", ..., denoting origin and should not enter the discussion about disttags! :) They also serve not technical functionality at all!
So if you want to build packages, you can do
o Red Hat style: no adorning at all foo-1.2.3-4 o With disttags: using for instance "fc1", "fc2": foo-1.2.3-4.fc1 o With disttags and repotags: using "ralf" as repotag: foo-1.2.4-4.fc1.ralf
Just start packaging for FC1 and FC2 and you will find out what the merits of a disttag are (and you will be crying for one ;)
On May 17, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
Or you pick the same release tag (for example "3") and add a different suffix that will always be rpm-less for FC1 than for FC2 like "fc1" and "fc2". The packages are now called foo-1.2-3.fc1 and foo-1.2-3.fc2 and you know that the true buildid is the "3" which can be used in ranged dependencies (Requires: foo >= 1.2-3).
Oh, that's what you want disttags for? Sorry, but it isn't going to work.
Consider that FC3 shipped with say foo-1.2-7.fc3. FC4 will probably undergo a few mass rebuilds, which will make foo-1.2-9.fc4 the package in FC4. While FC5 is under development, a security problem is found in foo, and the patch is back-ported into FC3 and FC4.
I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1 and foo-1.2-10.fc5 (rawhide), all of them containing the fix. You can't just use the version tag to identify packages containing the fix.
On Tue, 18 May 2004, Alexandre Oliva wrote:
Oh, that's what you want disttags for? Sorry, but it isn't going to work.
I disagree, it certainly can work, if used properly. This is exactly what many 3rd party repos are doing *right now*.
Consider that FC3 shipped with say foo-1.2-7.fc3. FC4 will probably undergo a few mass rebuilds, which will make foo-1.2-9.fc4 the package in FC4. While FC5 is under development, a security problem is found in foo, and the patch is back-ported into FC3 and FC4.
I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1 and foo-1.2-10.fc5 (rawhide), all of them containing the fix. You can't just use the version tag to identify packages containing the fix.
I think you miss the point. The point is to be able to release the "fixed" version as: foo-1.2-10.%{dist_tag} Isn't that *much* cleaner/simpler than your 7.fc3, 9.fc4, 10.fc5 example?
-- Rex
On Tue, May 18, 2004 at 08:15:54AM -0500, Rex Dieter wrote:
On Tue, 18 May 2004, Alexandre Oliva wrote:
Oh, that's what you want disttags for? Sorry, but it isn't going to work.
I disagree, it certainly can work, if used properly. This is exactly what many 3rd party repos are doing *right now*.
Yes, I always forget to underline that the disttag scheme is in place by almost all repos, (including fedora.us, aka not only the external "3rd parties") using the benefits outlined throughout this thread.
So it already got the field test for longer than a year now.
On May 18, 2004, Rex Dieter rdieter@math.unl.edu wrote:
On Tue, 18 May 2004, Alexandre Oliva wrote:
Oh, that's what you want disttags for? Sorry, but it isn't going to work.
I disagree, it certainly can work, if used properly. This is exactly what many 3rd party repos are doing *right now*.
Yeah, but they do it in a totally different way.
The way 3rd party repos do it is to have the very same sources built for multiple OS versions.
The way updates may be created is to take whatever shipped, install the patch that fixes the problem and rebuild that. This is more work, but it reduces the risk of instabilities and undesirable changes that upgrading to a newer version of the package represents.
Sure enough, Fedora Core updates aren't required to follow the procedures that used to be followed for Red Hat Linux errata, and that are still followed for Red Hat Enterprise Linux, but sometimes it's just the right thing to do.
I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1 and foo-1.2-10.fc5 (rawhide), all of them containing the fix. You can't just use the version tag to identify packages containing the fix.
I think you miss the point. The point is to be able to release the "fixed" version as: foo-1.2-10.%{dist_tag} Isn't that *much* cleaner/simpler than your 7.fc3, 9.fc4, 10.fc5 example?
It sort-of implies you use the same sources for all of the different OSs. This isn't necessarily a good idea. So the approach doesn't work in the general case.
On Tue, 18 May 2004, Alexandre Oliva wrote:
On May 18, 2004, Rex Dieter rdieter@math.unl.edu wrote:
On Tue, 18 May 2004, Alexandre Oliva wrote:
Oh, that's what you want disttags for? Sorry, but it isn't going to work.
I disagree, it certainly can work, if used properly. This is exactly what many 3rd party repos are doing *right now*.
Yeah, but they do it in a totally different way.
The way 3rd party repos do it is to have the very same sources built for multiple OS versions.
Yes, exactly. In the case where that is not true, dist_tags are harmless, so this shouldn't be used as an argument against using them.
-- Rex
On May 18, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Yes, exactly. In the case where that is not true, dist_tags are harmless, so this shouldn't be used as an argument against using them.
Not *totally* harmless.
Wasn't there a problem in the way old versions of rpm compared say -1.foo with -1.1.foo?
If you use disttags, and you have to patch a package such that the R number goes in between two R numbers that are already out, and you can't just append the build number at the end for the reasons Axel already exposed, and you can't add `.number' before the disttag, what do you do?
On Tue, May 18, 2004 at 04:44:48PM -0300, Alexandre Oliva wrote:
On May 18, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Yes, exactly. In the case where that is not true, dist_tags are harmless, so this shouldn't be used as an argument against using them.
Not *totally* harmless.
Wasn't there a problem in the way old versions of rpm compared say -1.foo with -1.1.foo?
Yes, so avoid comparing numbers and letters. OTOH it affects rpms Versions up to RH8.0 w/o errata upgrades. So probably one can consider this a corner case.
If you use disttags, and you have to patch a package such that the R number goes in between two R numbers that are already out,
Why would you do that? Say you have foo-1.2.3-4 and foo-1.2.3-5 and the fix comes out, you suggest foo-1.2.3-4.1 and foo-1.2.3-5.1. Wouldn't that make foo-1.2.3-5, one of the versions with the security vulnerability overwrite the fixed version from foo-1.2.3-4.1?
E.g. I have a secury FC3 and use an (outdated) FC4 installation medium to upgrade my system. Until I fire up the updater postinstallation my box is vulnerable.
So it is better to reach for higher bumbs in these cases.
There is nothing you can do, if the upstream version differs (other that doing the wrong thing, bumping epochs).
and you can't just append the build number at the end for the reasons Axel already exposed, and you can't add `.number' before the disttag, what do you do?
As said, this is an old corner stone, and using dotted releases should be considered deprecated anyway.
On May 18, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
If you use disttags, and you have to patch a package such that the R number goes in between two R numbers that are already out,
Why would you do that? Say you have foo-1.2.3-4 and foo-1.2.3-5 and the fix comes out, you suggest foo-1.2.3-4.1 and foo-1.2.3-5.1. Wouldn't that make foo-1.2.3-5, one of the versions with the security vulnerability overwrite the fixed version from foo-1.2.3-4.1?
E.g. I have a secury FC3 and use an (outdated) FC4 installation medium to upgrade my system. Until I fire up the updater postinstallation my box is vulnerable.
The assumption is that someone would immediately apply the FC4 updates, fixing the hole.
But think of fixes instead of security patches.
Consider that -5 had a change to make the package buildable on FC4, that would break on FC3.
Issuing -5.1 (or 6, for that matter) for both FC3 and FC4 implies it's newer than 5 for FC4. Should someone depend on the patch that made it buildable for FC4, and say so with a Requires: foo >= 1.2.3-5, issuing the errata as -5.1.FC3 might incorrectly satisfy the requirement.
As said, this is an old corner stone, and using dotted releases should be considered deprecated anyway.
I still think they should be used for the 0.<buildid> case, for *any* extras that might ever make it to the core (i.e., any extras at all :-)
On Tue, 18 May 2004, Alexandre Oliva wrote:
On May 18, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Yes, exactly. In the case where that is not true, dist_tags are harmless, so this shouldn't be used as an argument against using them.
Not *totally* harmless.
Wasn't there a problem in the way old versions of rpm compared say -1.foo with -1.1.foo?
I believe rpm-4.0 had a problem like what you describe. However, since redhat no longer supports anything with rpm-4.0, this should also be a non-issue, right? (-:
Besides, the case you mention case easily be avoided. *Always* use the same # of significant digits/dots in front of dist tag and/or simply increment the release, so you end up with either -1.0.foo -> -1.1.foo or -1.foo -> -2.foo
If you use disttags, and you have to patch a package such that the R number goes in between two R numbers that are already out, and you can't just append the build number at the end for the reasons Axel already exposed, and you can't add `.number' before the disttag, what do you do?
No problem. (-: Migrating *to* disttags actually helps in this case, and you avoid the problem you mentioned above because there is no existing dist_tag. Example, foo-1-3 and foo-1-5 are released now. Release patched version as: foo-1-3.0.%{dist_tag}
-- Rex
On May 18, 2004, Rex Dieter rdieter@math.unl.edu wrote:
On Tue, 18 May 2004, Alexandre Oliva wrote:
Besides, the case you mention case easily be avoided. *Always* use the same # of significant digits/dots in front of dist tag and/or simply increment the release, so you end up with either -1.0.foo -> -1.1.foo or -1.foo -> -2.foo
If you use disttags, and you have to patch a package such that the R number goes in between two R numbers that are already out, and you can't just append the build number at the end for the reasons Axel already exposed, and you can't add `.number' before the disttag, what do you do?
No problem. (-: Migrating *to* disttags actually helps in this case, and you avoid the problem you mentioned above because there is no existing dist_tag. Example, foo-1-3 and foo-1-5 are released now. Release patched version as: foo-1-3.0.%{dist_tag}
How about foo-1-3.fc3 and foo-1-4.fc4
How do I issue an errata for fc3?
3.1.fc3 (or 3.0.fc3?) won't work, because it causes numbers to be compared with letters. 3.fc3.1 won't work because upgrading to 4.fc4 will go backwards (I'm not sure I buy that, but it's not my argument, it's Axel's).
On Wed, 19 May 2004 11:36:54 -0500, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
How about foo-1-3.fc3 and foo-1-4.fc4
How do I issue an errata for fc3?
foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)
or better, release 2 updates foo-1-5.fc3 and foo-1-5.fc4
release foo-1.5.fc4 even if foo-1.4.fc4 was not actually affected by the errata?
yeah...lets design a package naming policy that demands package updates on systems that are not directly affected by security errata. won't it be fun..when users start having to eat large package updates like the kernel or openoffice, just because the packaging naming scheme makes rolling an update mandatory. Yeah, excuse me while i walk to the corner of my office and throw up.
-jef
Jeff Spaleta wrote:
release foo-1.5.fc4 even if foo-1.4.fc4 was not actually affected by the errata?
I said it was an option, not a requirement to release foo-1-5.fc4.
yeah...lets design a package naming policy that demands package updates on systems that are not directly affected by security errata.
Oh please stop exagerating. It's not *that* bad. If it makes you feel better, I'll even bring you a bucket for your throw up... (-:
Speaking of useless large package updates, why does redhat bundle koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice and k3b rpms, so that any updates to koffice and k3b will also "force users to eat useless large updates"?
Hint: we're touching on similar issues here. I realize things are not so cut-and-dried.
-- Rex
On Wed, 19 May 2004 12:23:31 -0500, Rex Dieter rdieter@math.unl.edu wrote:
Speaking of useless large package updates, why does redhat bundle koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice and k3b rpms, so that any updates to koffice and k3b will also "force users to eat useless large updates"?
I hear there is this wonderful thing that rpm has called obsoleting..... so that if a specific package is decided to be split or combined later on down the road, it can be handled gracefully.
what you are suggesting is a mandatory rebuild of any packages as a matter of overreaching naming policy....for the entire collection of packages. In a world full of shades of gray, the contrast setting in this argument is set pretty high.
And you still have not addressed the issue of how to handle backported fixes. So far in this example you are talking about replace foo-1.3 with foo-1.4 or foo-1.5. The actually problem is how to roll backported fixes. Applying targetted fixes to foo-1.3 does not make it foo-1.4 or foo-1.5. foo-1.4 and foo-1.5 upstream could very well include change in functionality beyond the needed fixes. It is not always appropriate to bump a package up to the next version. You can either accept that backport fixes will be needed and the naming policy will need to be flexible enough to handle that, or you can't accept it. Until you accept the need for that situation, I'm not sure any further discussion on the list about this is worth having.
-jef
On Wed, 19 May 2004 12:49:42 -0500, Rex Dieter rdieter@math.unl.edu wrote:
Isn't fedora's policy now, in general, to *not* backport fixes, but to upgrade to the latest upstream version?
what does "in general" really mean? It certaintly doesn't mean garunteed, absolutely not going to need to do backports. Do the right thing for the right reasons for the right package. I'm sure upstream latest versions of applications will be very common. I'm not so certain that upstream latest versions will always be appropriate for the library level nor the kernel itself. The point is any naming policy must be flexible enough to ensure that backporting fixes and building patched errata still has a place to work smoothly, especially because anything important enough to require a backport over a latest version push is going to be VERY important and need to update smoothly since these sorts of things tend to be security related. Building a naming policy that makes trivial feature updates work with mindnumbing automated ease...but makes critically important security backported package updates a pain in the ass to install...is short sighted.
-jef
Jeff Spaleta wrote:
On Wed, 19 May 2004 12:49:42 -0500, Rex Dieter rdieter@math.unl.edu wrote:
Isn't fedora's policy now, in general, to *not* backport fixes, but to upgrade to the latest upstream version?
what does "in general" really mean?
I'm refering to item #3 on http://fedora.redhat.com/about/objectives.html QUOTE: "3. Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages."
-- Rex
On Wed, 19 May 2004 13:03:03 -0500, Rex Dieter rdieter@math.unl.edu wrote:
"3. Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages."
As much as possible..does not mean its always going to be possible. A promise to avoid the need for a backport doesn't mean its not going to be needed...critically needed. Building a general naming policy that doesn't leave room for package mainters and leadership to provide critical security backports when moving to upstream latest is not the right thing to do, is a mistake,
IMHO, The only reason dist_tags can possibly cause any sort of problems with backported fixes is dealing with rpm < 4.2 (or possibly rpm < 4.1 where is incorrectly sorts numerics vs. alphas in version/release tags). In the scope of *this* discussion, we're dealing only with non-buggy rpm versions, so Fedora Core can safely ignore those problems(*). Futher, in the lack of existing dist_tags, these problems go > away.
You know, i dont think we can assume that at all. I bet the 3rd party repository maintainers that are pushing hard for distag to be the policy want to make damn sure, that the policy works for all the distros they are trying to build packages for including all those old red hat releases with those older rpm versions because they want their build system to be as automated as possible.
And of course this makes an assumption that the fedora core buildsystem wont have to be constrained by the rhel build process requirements. I can not speak knowledgably about how much of a burden tagging like this will place on maintainers who have to consider using a codebase for both fedora and rhel packages. But I don't think we can assume out of hand that whatever fedora core buildsys does is going to be without constraint on how rhel packaging building works. So for the sake of discussion i dont know if we can assume a buggy rpm is outside the bounds of the problem. Fedora project policy is not going to live in a vacuum, and we do not know enough about the Core buildsystem to know if rhel packaging considerations have to be taken into account in packaging naming or not.
-jef
Jeff Spaleta wrote:
On Wed, 19 May 2004 13:03:03 -0500, Rex Dieter rdieter@math.unl.edu wrote:
"3. Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages."
As much as possible..does not mean its always going to be possible.
And that's why I said upstream versions are the default, only in general. Other cases are the exception, not the rule (or the majority either).
-- Rex
Jeff Spaleta wrote:
And you still have not addressed the issue of how to handle backported fixes.
IMHO, The only reason dist_tags can possibly cause any sort of problems with backported fixes is dealing with rpm < 4.2 (or possibly rpm < 4.1 where is incorrectly sorts numerics vs. alphas in version/release tags). In the scope of *this* discussion, we're dealing only with non-buggy rpm versions, so Fedora Core can safely ignore those problems(*). Futher, in the lack of existing dist_tags, these problems go away.
So, given foo-1-3 (for fc3) and foo-1-4 (for fc4), an fc3 errata can use any of these safely:
If paranoid about upgrades to fc4, so foo-1-4 is *always* newer/greater: foo-1-3.0.fc3 (my personal preference) foo-1-3.fc3 (*just* adding dist_tag) And by extension, a possible 2nd errata: foo-1-3.1.fc3
Or to simpify things for the packager(s), and always use a single source (and yes, possibly pushing out useless updates on some platforms): foo-1-5.%{dist_tag}
-- Rex
(*) Or possibly someone (RedHat, fedora.us, or fedoralegacy.org) can release an rpm errata to fix these issues as well.
On Wed, May 19, 2004 at 01:01:11PM -0500, Rex Dieter wrote:
In the scope of *this* discussion, we're dealing only with non-buggy rpm versions, so Fedora Core can safely ignore those problems(*).
(*) Or possibly someone (RedHat, fedora.us, or fedoralegacy.org) can release an rpm errata to fix these issues as well.
This has already been done, by Jeff Johnson at rpm.org (the unofficial never-made-it-to-official-but-why errate), ATrpms, fedora.us, fedoralegacy, ...
The reason for these errata was not the letters-vs-numbers or rpm-non-symmetric bug, but the database corruption and locking issues.
So, if you have the numbers-and-letters bug, then this bug will be the least you care about ...
Ergo: We can now safely assume rpm handles numbers and letters correctly. Especially in the scope of the Fedora Project, as well as for Red Hat's other product lines (the RHEL family).
(I hope I didn't lie about RHEL, someone please confirm).
On Wed, 19 May 2004 12:23:31 -0500, Rex Dieter wrote:
Speaking of useless large package updates, why does redhat bundle koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice and k3b rpms, so that any updates to koffice and k3b will also "force users to eat useless large updates"?
Avoiding special hooks in the installer and in post-install package tools. Consider "Add Languages" functionality.
For extra repositories this is also an issue, but a less important one currently as one can obsolete i18n packages in an update any time.
On Wed, 19 May 2004, Michael Schwendt wrote:
On Wed, 19 May 2004 12:23:31 -0500, Rex Dieter wrote:
Speaking of useless large package updates, why does redhat bundle koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice and k3b rpms, so that any updates to koffice and k3b will also "force users to eat useless large updates"?
For extra repositories this is also an issue, but a less important one currently as one can obsolete i18n packages in an update any time.
But difficult to the other direction.
--Rex
On Sat, 22 May 2004 07:25:13 -0500 (CDT), Rex Dieter wrote:
On Wed, 19 May 2004, Michael Schwendt wrote:
On Wed, 19 May 2004 12:23:31 -0500, Rex Dieter wrote:
Speaking of useless large package updates, why does redhat bundle koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice and k3b rpms, so that any updates to koffice and k3b will also "force users to eat useless large updates"?
[some part of the quote is missing here]
For extra repositories this is also an issue, but a less important one currently as one can obsolete i18n packages in an update any time.
But difficult to the other direction.
That's the same problem as referred to in the part that's missing in above quote. [Unless package tools are tuned to "know about" i18n packages and pull them in when necessary.]
On Sat, 22 May 2004, Michael Schwendt wrote:
On Sat, 22 May 2004 07:25:13 -0500 (CDT), Rex Dieter wrote:
On Wed, 19 May 2004, Michael Schwendt wrote:
On Wed, 19 May 2004 12:23:31 -0500, Rex Dieter wrote:
Speaking of useless large package updates, why does redhat bundle koffice-i18n, k3b-i18n (these are just 2 examples) into the main koffice and k3b rpms, so that any updates to koffice and k3b will also "force users to eat useless large updates"?
[some part of the quote is missing here]
For extra repositories this is also an issue, but a less important one currently as one can obsolete i18n packages in an update any time.
But difficult to the other direction.
That's the same problem as referred to in the part that's missing in above quote. [Unless package tools are tuned to "know about" i18n packages and pull them in when necessary.]
I personally could care less about lacking features in the installer/package-manager. I care more about removing the "choice" and forcing the installation of these i18n files/pkgs upon all users, whether they want/need it or not.
-- Rex
On May 19, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
How about foo-1-3.fc3 and foo-1-4.fc4 How do I issue an errata for fc3?
foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)
But this breaks foo >= 1-4
or better, release 2 updates foo-1-5.fc3 and foo-1-5.fc4
This breaks because 1-5.fc3 > 1-4.fc4, and 5.fc3 isn't suitable for FC4 because it doesn't contain the change introduced in 1-4.fc4 that makes it work on FC4.
Alexandre Oliva wrote:
On May 19, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
How about foo-1-3.fc3 and foo-1-4.fc4 How do I issue an errata for fc3?
foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)
But this breaks foo >= 1-4
I don't follow. How exactly does it break?
or better, release 2 updates foo-1-5.fc3 and foo-1-5.fc4
This breaks because 1-5.fc3 > 1-4.fc4, and 5.fc3 isn't suitable for FC4 because it doesn't contain the change introduced in 1-4.fc4 that makes it work on FC4.
That's what the foo-1-5.fc4 update/release is for.
-- Rex
On May 19, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
On May 19, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
How about foo-1-3.fc3 and foo-1-4.fc4 How do I issue an errata for fc3?
foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)
But this breaks foo >= 1-4
I don't follow. How exactly does it break?
Your foo-1-4.fc3 won't contain the change made in 1-4.fc4, that is required for FC4, but must not be present in FC3.
If a package requires foo >= 1-4, it's safe to assume that it requires that change, and 1-4.fc3 won't have it, so things will break.
Alexandre Oliva wrote:
On May 19, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
On May 19, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
How about foo-1-3.fc3 and foo-1-4.fc4 How do I issue an errata for fc3?
foo-1-4.fc3 (which is still smaller than foo-1.4.fc4)
But this breaks foo >= 1-4
I don't follow. How exactly does it break?
Your foo-1-4.fc3 won't contain the change made in 1-4.fc4, that is required for FC4, but must not be present in FC3.
Right.
If a package requires foo >= 1-4, it's safe to assume that it requires that change, and 1-4.fc3 won't have it, so things will break.
OK. This is part of the minor pain that must be endured to start using dist_tags. No one said it would be 100% seamless. I consider these side-effects to be insignificant next to the major advantages that dist_tags bring to the table.
In this case, multiple erratas must be released:
The package that *had* contained: Requires: foo >= 1-4 now should be: Requires: foo > 1-4
And release foo-1-4.fc3 and foo-1-4.fc4
-- Rex
On Wed, May 19, 2004 at 01:27:40PM -0300, Alexandre Oliva wrote:
On May 18, 2004, Rex Dieter rdieter@math.unl.edu wrote:
On Tue, 18 May 2004, Alexandre Oliva wrote:
Besides, the case you mention case easily be avoided. *Always* use the same # of significant digits/dots in front of dist tag and/or simply increment the release, so you end up with either -1.0.foo -> -1.1.foo or -1.foo -> -2.foo
If you use disttags, and you have to patch a package such that the R number goes in between two R numbers that are already out, and you can't just append the build number at the end for the reasons Axel already exposed, and you can't add `.number' before the disttag, what do you do?
No problem. (-: Migrating *to* disttags actually helps in this case, and you avoid the problem you mentioned above because there is no existing dist_tag. Example, foo-1-3 and foo-1-5 are released now. Release patched version as: foo-1-3.0.%{dist_tag}
How about foo-1-3.fc3 and foo-1-4.fc4
How do I issue an errata for fc3?
If foo-1-4 is already fixed, e.g. needs no errata, then you must fork the buggy foo-1-3 into decimals, to place it before foo-1-4, for example foo-1-3.1
So you get with added disttags:
foo-1-3.fc3 foo-1-3.1.fc3 foo-1-4.fc4
in rpm's sort order.
3.1.fc3 (or 3.0.fc3?) won't work, because it causes numbers to be compared with letters.
Only for non-updated Red Hat 8.0 and before, which means that your rpm database is anyway out of order at every second install. So, we can assume a working rpm.
3.fc3.1 won't work because upgrading to 4.fc4 will go backwards (I'm not sure I buy that, but it's not my argument, it's Axel's).
Well, would you prefer a buggy/insecure version built for fc4, or the fixed one for fc3, but built against an older glibc? This preference defines the rpm sort order you are going to give to the errata packages.
E.g. you either fix both (if both versions are vulerable) separately to foo-1-3.1.fc3 and foo-1-4.1.fc4
or you release a common erratum like foo-1-5.fc3 foo-1-5.fc4
You still have both choices.
As you noted (I mean Alexandre), there can be a problem with letters and numbers mixing, when the _number of_ the segments before the disttag change (like being done for forked timelines).
But this is only for a buggy rpm. If we would really want to be safe, we shouldn't also use comparision of equal substrings, e.g. "1" vs "1.1", as this had been another (older) rpm bug.
We do need to define some basic functionality for rpm to be able to do anything with it, and IMHO we can and should assume the letter/numbers mixing bug as fixed.
Otherwise all of fedora.us would suffer from this, as there the disttags from RHL to FC jumped from letters and numbers. And obviously this issue has not been observed too often.
Disttags are good, not evil :)
Persuaded? If yes, how many disbelieving Red Hat developers are there to continue? ;)
If not, let's go on with the discussion in half a year, perhaps the merger with fedora.us will increase the necessity for disttags.
On Tue, May 18, 2004 at 08:43:11AM -0300, Alexandre Oliva wrote:
On May 17, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
Or you pick the same release tag (for example "3") and add a different suffix that will always be rpm-less for FC1 than for FC2 like "fc1" and "fc2". The packages are now called foo-1.2-3.fc1 and foo-1.2-3.fc2 and you know that the true buildid is the "3" which can be used in ranged dependencies (Requires: foo >= 1.2-3).
Oh, that's what you want disttags for?
One of its used, yes (I enumerated some at the start of this thread ;)
Sorry, but it isn't going to work.
Consider that FC3 shipped with say foo-1.2-7.fc3. FC4 will probably undergo a few mass rebuilds,
Gotya! One of the other uses for a disttag is tha a mass-rebuild does not need to bump the release tag of each innocent rpm, but can have them bumped through the disttag, for example:
fc2.89.103 (the 103rd mass rebuild in fc3 developement) New glibc gets pushed out, command to rebuild every rpms gets out. Elliot changes disttag to fc2.89.104, hits a button on the build system and goes to have some coffee or tee.
This scenario is not science fiction, it already works with the existing disttag schemes.
But that is "just another use" of disttags.
I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1 and foo-1.2-10.fc5 (rawhide), all of them containing the fix. You can't just use the version tag to identify packages containing the fix.
If the buggy version was foo-1.2-7, then the fixed is
foo-1.2-8.fc3 foo-1.2-8.fc4 foo-1.2-8.fc4.89.105
The idea is that trivial changes like rebuilds don't even need to bumb the release tag (or the buildid component).
It does become trickier, if the different distros are based on different _upstream versions_ and you have a policy of non-upgrading, but only minimal backports (like RHEL or RHL). While this is not the usual case with FC's policies, one must admit that this cannot be fixed with disttags, you have genuine functional forks at differnt timelines in this case.
Hey, disttags aren't considered the solution to everything, they only make life easier, but not yet trivial ;)
On May 18, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1 and foo-1.2-10.fc5 (rawhide), all of them containing the fix. You can't just use the version tag to identify packages containing the fix.
If the buggy version was foo-1.2-7, then the fixed is
foo-1.2-8.fc3 foo-1.2-8.fc4 foo-1.2-8.fc4.89.105
All of the above had the bug and have to be fixed, and -8 won't do it for them.
The idea is that trivial changes like rebuilds don't even need to bumb the release tag (or the buildid component).
That's good. But it still doesn't cover the case of patches being added to the package, which is what got foo-1.2 bumped from -7 to -9 between FC3 and FC4.
On Tue, May 18, 2004 at 04:01:22PM -0300, Alexandre Oliva wrote:
On May 18, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1 and foo-1.2-10.fc5 (rawhide), all of them containing the fix. You can't just use the version tag to identify packages containing the fix.
If the buggy version was foo-1.2-7, then the fixed is
foo-1.2-8.fc3 foo-1.2-8.fc4 foo-1.2-8.fc4.89.105
All of the above had the bug and have to be fixed, and -8 won't do it for them.
No, there would not have been the -9 and -10 versions (because the rebuilds are controlled via the disttag).
Otherwise use "11" instead of "8".
The idea is that trivial changes like rebuilds don't even need to bumb the release tag (or the buildid component).
That's good. But it still doesn't cover the case of patches being added to the package, which is what got foo-1.2 bumped from -7 to -9 between FC3 and FC4.
I still believe in common specfiles and src.rpm, so I would make the application of patches conditional on the disttag, or the environment probing, e.g. apply ntpl patches only if built on an ntpl platform.
And if that is not an acceptable solution, well, disttags cannot solve everything for you, you've got to do also something ;)
The bottom line is disttags bring a lot of benefits as can bee seen in their implementation in the wild, have caused no harm, and come at very little expense.
On May 18, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
The bottom line is disttags bring a lot of benefits as can bee seen in their implementation in the wild, have caused no harm, and come at very little expense.
I don't see benefits for the core proper, and I do see problems. So it's not as clear-cut as you say. The reality of add-on repositories is quite different because their goal is to use the same package on multiple OSs. Issuing updates doesn't work that way.
On Tue, May 18, 2004 at 06:36:11PM -0300, Alexandre Oliva wrote:
On May 18, 2004, Axel Thimm Axel.Thimm@ATrpms.net wrote:
The bottom line is disttags bring a lot of benefits as can bee seen in their implementation in the wild, have caused no harm, and come at very little expense.
I don't see benefits for the core proper, and I do see problems. So it's not as clear-cut as you say. The reality of add-on repositories is quite different because their goal is to use the same package on multiple OSs. Issuing updates doesn't work that way.
While there are benefits for the core (automatic rawhide rebuilds, easier identification of fixes due to no unneccessary release bumbing, common errata), the Fedora project is not only core.
As this is a problem discussed many times in the community and reaching for Red Hat's participation, you cannot close your scope onto core only. Common specs and guidelines are needed, and packages should be technically treated equally, e.g. they should not have to be rewritten to move to core for example, core, extras, and anything else should blend in nicely in a canonical scheme.
Anyway this discussion only raised the interest of two Red Hat developers, which weren't convinced about the idea (although Alexandre was close at some time). I'd say it still cannot penetrate into Red Hat, we'll try again in half a year ;)
On 18 May 2004 18:36:11 -0300, Alexandre Oliva wrote:
On May 18, 2004, Axel Thimm Axel.Thimm@ATrpms.xxx wrote:
The bottom line is disttags bring a lot of benefits as can bee seen in their implementation in the wild, have caused no harm, and come at very little expense.
I don't see benefits for the core proper, and I do see problems. So it's not as clear-cut as you say. The reality of add-on repositories is quite different because their goal is to use the same package on multiple OSs. Issuing updates doesn't work that way.
Disttags aren't as flexible as advertized, unless you create an ugly hierarchy such as rh73 < rh80 < rhfc1 < rhfc2 and so on. And that doesn't include Red Hat Enterprise Linux yet.
On Tue, May 18, 2004 at 11:58:26PM +0200, Michael Schwendt wrote:
On 18 May 2004 18:36:11 -0300, Alexandre Oliva wrote:
On May 18, 2004, Axel Thimm Axel.Thimm@ATrpms.xxx wrote:
The bottom line is disttags bring a lot of benefits as can bee seen in their implementation in the wild, have caused no harm, and come at very little expense.
I don't see benefits for the core proper, and I do see problems. So it's not as clear-cut as you say. The reality of add-on repositories is quite different because their goal is to use the same package on multiple OSs. Issuing updates doesn't work that way.
Disttags aren't as flexible as advertized, unless you create an ugly hierarchy such as rh73 < rh80 < rhfc1 < rhfc2 and so on. And that doesn't include Red Hat Enterprise Linux yet.
and it never should, because RHEL is officially unrelated to FC, e.g. there will be no supported upgrade path between FC and RHEL.
And yes, if you don't make sure the disttags are sorted well within the considered distribution family then we are not talking about disttags, so the comment isn't really helpful.
So what's your constructive suggestion?
Michael Schwendt wrote:
Disttags aren't as flexible as advertized, unless you create an ugly hierarchy such as rh73 < rh80 < rhfc1 < rhfc2 and so on. And that doesn't include Red Hat Enterprise Linux yet.
Let's leave the merits of disttags and their robust implementation as separate discussions. You're addressing the latter, which certainly can, IMO, be done well.
-- Rex
On May 19, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
I don't see benefits for the core proper, and I do see problems. So
What problems?
Err... The ones I described in my recent postings in this thread?
On Wed, 19 May 2004, Alexandre Oliva wrote:
On May 19, 2004, Rex Dieter rdieter@math.unl.edu wrote:
Alexandre Oliva wrote:
I don't see benefits for the core proper, and I do see problems. So
What problems?
Err... The ones I described in my recent postings in this thread?
And I thought I rebutted those...
-- Rex
Hello,
Since 3 days ago, from the last upgrade of up2date, whenever I try to run it, the result is the following:
[root@200-207-17-55 casimiro]# up2date --update http://fedora.redhat.com/download/up2date-mirrors/fedora-core-2 using mirror: http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/2/i386/o... http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc2 using mirror: http://mirror.eas.muohio.edu/fedora/linux/core/updates/2/i386/ There was a fatal error communicating with the server. The message was:
An HTTP error occurred: URL: http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/2/i386/o... Status Code: 404 Error Message: Not Found
I tried to manually download up2date from fedora and run rpm -Uvh... but the result is the same.
Looking for the pointed URL, it really doesn't exist (was directory moved without notice ???)
Regards,
Casimiro Barreto
I'm not sure about the major release version that you have, i.e., "2"... you might wanna change that to "development"
the directory "2" is currently not available because core 2 is not yet a "go"...... or at least i wasn't able to access it on ibiblio.org. but yea, rawhid is still under development
so yea, check out /etc/yum.conf and change the settings appropriately. did you, btw, change the "$releasever" into "2"?
see ya, paul
At 05:16 AM 5/14/2004, you wrote:
Hello,
Since 3 days ago, from the last upgrade of up2date, whenever I try to run it, the result is the following:
[root@200-207-17-55 casimiro]# up2date --update http://fedora.redhat.com/download/up2date-mirrors/fedora-core-2 using mirror: http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/2/i386/o... http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc2 using mirror: http://mirror.eas.muohio.edu/fedora/linux/core/updates/2/i386/ There was a fatal error communicating with the server. The message was: An HTTP error occurred: URL: http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/2/i386/o... Status Code: 404 Error Message: Not Found
I tried to manually download up2date from fedora and run rpm -Uvh... but the result is the same.
Looking for the pointed URL, it really doesn't exist (was directory moved without notice ???)
Regards,
Casimiro Barreto
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
_________ Paul Rigor pryce@ucla.edu Go Bruins!
On Wed, 2004-05-12 at 10:11, Warren Togami wrote:
Ralf Corsepius wrote:
Hi,
I am planing to release a couple of rpms which are supposed to be add-on packages to Fedora Core and/or Fedora Extras.
What is the current convention on choosing rpm release tags for such packages to provide co-existence for such kind of packages?
AFAIS, from freshrpms, livna, atrpms none there doesn't seem to exist such kind of convention. Conversely, all seem to be designed "to take over the system".
http://www.fedora.us/wiki/PackageSubmissionQAPolicy http://www.fedora.us/wiki/PackageNamingGuidelines If you follow these rules you generally will not clash with FC packages, but it takes a little practice to get it right. The other volunteers will help you if you make mistakes, so don't worry. It would help if you submit your packages to fedora.us QA just so other people know it exists. (That process will NOT become easier when the SCM goes online, because only trusted & proven developers will have any checkin access at all, while everyone else must earn that trust through demonstrated hard work and dedication.)
Some background info: I have a local repository of locally built RPMs, I am considering some of them for submission to Fedora.Us/Extra/Legacy and some of them for submission to 3rd party repositories, e.g. because some of them are of too little general interest.
Therefore I want to choose these rpms release tags in such a way that they "play it nicely" with Fedora Core and Fedora Extras.
I.e. I want choose my rpm tags in such a way, that Fedora Core/Updates/Extras/Legacy packages shall replace my rpms once Fedora Core/Updates/Extras/Legacy should release the same packages.
I assume you mean by "taking over the system" you mean replacing packages that are within the core distribution?
I meant co-existence of packages from different origins (mixing Fedora Core and Extras with 3rd party sources of RPMs).
fedora.us and livna does not do that at all.
Theoretical example: Suppose the legal situation of a package changes, and you would consider to move this package from Livna to Fedora Extras. How would you deal with that?
ATM, Fedora/Stable uses 0.fdr.x.1, Livna uses 0.lvn.y.1.
RPM-wise, a package using 0.lvn* will always be greater than a package using 0.fdr*. Now, you could increase the Epoch for the fdr package - Not necessarily a good solution, IMHO. You could increase the actual "release number" (use 1.fdr.*) - AFAIU, this would contradict the Fedora.US versioning policy, because it would cause problems with Fedora Core.
The other 3rd party repositories are controlled by single persons and they generally do whatever they want unilaterally, for better or worse.
That's why I am looking for "the better solution". Or to bring it to the point: Which release-tag do you (Fedora US) recommend for my purposes?
Ralf
On Wed, 12 May 2004 12:41:42 +0200, Ralf Corsepius wrote:
Therefore I want to choose these rpms release tags in such a way that they "play it nicely" with Fedora Core and Fedora Extras.
I.e. I want choose my rpm tags in such a way, that Fedora Core/Updates/Extras/Legacy packages shall replace my rpms once Fedora Core/Updates/Extras/Legacy should release the same packages.
That's what the fedora.us package naming guidelines address. You can find the Fedora Legacy package naming guidelines on their own website.
Theoretical example: Suppose the legal situation of a package changes, and you would consider to move this package from Livna to Fedora Extras. How would you deal with that?
ATM, Fedora/Stable uses 0.fdr.x.1, Livna uses 0.lvn.y.1.
It's the classical "repotags suck" example. :)
Similarly, disttags cause problems too, so preferably the ".fdr" and ".lvn" would be dropped.
You could increase the actual "release number" (use 1.fdr.*) - AFAIU, this would contradict the Fedora.US versioning policy, because it would cause problems with Fedora Core.
Which would be fine nevertheless, since at some point in time, a bit of coordinating would not hurt and existing packages in fedora.us should not be ignored.
Or to bring it to the point: Which release-tag do you (Fedora US) recommend for my purposes?
Stick to the current one for the time being.
Ralf Corsepius wrote:
ATM, Fedora/Stable uses 0.fdr.x.1, Livna uses 0.lvn.y.1.
RPM-wise, a package using 0.lvn* will always be greater than a package using 0.fdr*.
Unless you know your packages are definitely non-free, use fdr
-- Rex
p.s. It has been argued that the repo_tag part of the release should appear *at the very end* for the very reason you describe.
-
Alexandre Oliva -
Axel Thimm -
Casimiro de Almeida Barreto -
Jef Spaleta -
Michael Schwendt -
Nils Philippsen -
Paul Rigor -
Ralf Corsepius -
Rex Dieter -
Steven Pritchard -
Warren Togami