Hi, I wonder why some packages are named like:
cman-1.0.5-0.FC5.1.i386.rpm (with capital FC5)
some are named like: compat-gcc-32-g77-3.2.3-55.fc5.i386.rpm
but most of them don't have any fc5 tag Is there any pattern in this?
On Tue, Mar 28, 2006 at 12:56:17PM +0100, Rafa³ Kwa¶ny wrote:
I wonder why some packages are named like:
cman-1.0.5-0.FC5.1.i386.rpm (with capital FC5)
some are named like: compat-gcc-32-g77-3.2.3-55.fc5.i386.rpm
but most of them don't have any fc5 tag Is there any pattern in this?
Note that you're not asking about package names, but about the release numbering scheme.
Good question, anyway, as this looks pretty *packager*-dependent, which it should not be, IMHO.
On Tue, 28 Mar 2006 12:56:17 +0100, Rafał Kwaśny wrote:
Hi, I wonder why some packages are named like:
cman-1.0.5-0.FC5.1.i386.rpm (with capital FC5)
some are named like: compat-gcc-32-g77-3.2.3-55.fc5.i386.rpm
but most of them don't have any fc5 tag Is there any pattern in this?
No pattern. Core package developers can do what they want, and some of them still don't seem to care that .fc3 is "newer than" .FC5 in RPM version comparison.
In Fedora Extras, the distribution tag in the "Release" version number is optional. But when used (through a macro in the package spec file), it is inserted as lower-case .fc5 by the build-system.
On Tue, 2006-03-28 at 14:42 +0200, Michael Schwendt wrote:
No pattern. Core package developers can do what they want, and some of them still don't seem to care that .fc3 is "newer than" .FC5 in RPM version comparison.
That's a bit of an exaggeration. It's not that we don't care, it's that it doesn't matter unless you're doing something *else* really dumb at the same time as *switching* between those two nomenclatures.
*yawn*.
On Tue, 28 Mar 2006 16:47:50 -0500, Peter Jones wrote:
No pattern. Core package developers can do what they want, and some of them still don't seem to care that .fc3 is "newer than" .FC5 in RPM version comparison.
That's a bit of an exaggeration. It's not that we don't care, it's that it doesn't matter unless you're doing something *else* really dumb at the same time as *switching* between those two nomenclatures.
*yawn*.
No need to yawn. :) It has happened before that a package from Core was moved to Extras or vice versa, and then you get the "switching" in updates unless the different packagers agree on a common way.
On Wed, 2006-03-29 at 15:37 +0200, Michael Schwendt wrote:
On Tue, 28 Mar 2006 16:47:50 -0500, Peter Jones wrote:
No pattern. Core package developers can do what they want, and some of them still don't seem to care that .fc3 is "newer than" .FC5 in RPM version comparison.
That's a bit of an exaggeration. It's not that we don't care, it's that it doesn't matter unless you're doing something *else* really dumb at the same time as *switching* between those two nomenclatures.
*yawn*.
No need to yawn. :) It has happened before that a package from Core was moved to Extras or vice versa, and then you get the "switching" in updates unless the different packagers agree on a common way.
Ok, but there's a more serious problem there. If you're moving the package from core to extras or vice versa, start with the same spec file and only change the parts you actually have to.
If our naming policy for extras says we have to use one particular capitalization for a "release" field, then we should fix it. That's just a rule for the sake of having more rules. It doesn't buy us anything.
2006/3/29, Peter Jones pjones@redhat.com:
On Wed, 2006-03-29 at 15:37 +0200, Michael Schwendt wrote:
On Tue, 28 Mar 2006 16:47:50 -0500, Peter Jones wrote:
No pattern. Core package developers can do what they want, and some of them still don't seem to care that .fc3 is "newer than" .FC5 in RPM version comparison.
That's a bit of an exaggeration. It's not that we don't care, it's that it doesn't matter unless you're doing something *else* really dumb at the same time as *switching* between those two nomenclatures.
*yawn*.
No need to yawn. :) It has happened before that a package from Core was moved to Extras or vice versa, and then you get the "switching" in updates unless the different packagers agree on a common way.
Ok, but there's a more serious problem there. If you're moving the package from core to extras or vice versa, start with the same spec file and only change the parts you actually have to.
If our naming policy for extras says we have to use one particular capitalization for a "release" field, then we should fix it. That's just a rule for the sake of having more rules. It doesn't buy us anything.
-- Peter
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
well actually while i am also a fan of practicable solutions... either there are packaging guidelines... or there arent...
if only half of fedora packages are done according to the guidelines i ask myself why the other half is forced wasting time with doing it.
I see only one particular solution there... either drop the rules in general... or have the rules apply everywhere.
regards, Rudolf Kastl
On Wed, 2006-03-29 at 14:30 -0500, Peter Jones wrote:
Ok, but there's a more serious problem there. If you're moving the package from core to extras or vice versa, start with the same spec file and only change the parts you actually have to.
If our naming policy for extras says we have to use one particular capitalization for a "release" field, then we should fix it. That's just a rule for the sake of having more rules. It doesn't buy us anything.
In extras, we use a %{dist} macro in the spec, that's automatically set by the build system. And the build system uses lowercase. That's the rule.
What does this rule buy us? The same spec can be used to build for multiple distro versions.
devel@lists.stg.fedoraproject.org
-
Callum Lerwick -
Jos Vos -
Michael Schwendt -
Peter Jones -
Rafał Kwaśny -
Rudolf Kastl