Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers.
http://fedoraproject.org/wiki/PackageNamingGuidelines
Feedback is welcome, and encouraged.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Wed, Feb 23, 2005 at 02:18:10PM -0600, Tom 'spot' Callaway wrote:
Feedback is welcome, and encouraged.
In section 1.2 "Multiple packages with the same base name" you might want to mention the exception: parallel-installable packages, like kernel (and kernel-module-*).
Otherwise, looks good.
On Wed, 2005-02-23 at 14:18 -0600, Tom 'spot' Callaway wrote:
Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers.
http://fedoraproject.org/wiki/PackageNamingGuidelines
Feedback is welcome, and encouraged.
First of all a big thank you for doing this, a packaging standard for Extras (and for Core as well I hope!) is certainly most welcome and <cough> somewhat overdue :)
Some comments after a quick read-through:
1) Version and release-tags: Package version should obviously follow upstream version in normal, sane cases but especially things like 1.0- pre1 need special rules to handle without epochs, those should be covered in this doc. The old fedora.us packaging guidelines doc, section C-3 (http://www.fedora.us/wiki/PackageNamingGuidelines) pretty much covers these cases if you drop the 0.fdr tags from the rules.
2) While at versions and releases: can we *please* have a standard on release-tags. Current FC trees have a wild variety of things in there like "3jpp_2fc", in general a truly random FC3 vs fc2 dist-tags for some packages (disttags are just fine when needed but can we standardize on lowercase like with package names, please :) .. and so on. Just do 'rpm -qp --qf "%{release}\n" *|sort -u' on current FC-devel RPMS directory for giggles. Please let's have a standard of allowed characters in release and version tags as well since we're having one for names?
3) Addon packages: when a package is renamed, eg 'adodb' -> 'php-adodb' it *might* be a good idea to add the original name as a "Provides: adodb" so people looking for upstream naming can find it more easily.
Oh and FWIW current rawhide contains quite a few packages other than pam_ and SDL_ with underscores in the name (see below). Of these the various apache mod_foo packages are numerous enough to warrant an exception rule of their own, others should perhaps be renamed?
[pmatilai@chip RPMS]$ rpm -qp --qf "%{name}\n"|grep _ arptables_jf dhcpv6_client java_cup java_cup-javadoc java_cup-manual knm_new libart_lgpl libart_lgpl-devel lm_sensors lm_sensors-devel microcode_ctl mod_auth_kerb mod_auth_mysql mod_auth_pgsql mod_authz_ldap mod_dav_svn mod_perl mod_perl-devel mod_python mod_ssl nss_db nss_db-compat nss_ldap sg3_utils tcp_wrappers ttfonts-zh_CN ttfonts-zh_TW
- Panu -
On Wed, Feb 23, 2005 at 11:17:32PM +0200, Panu Matilainen wrote:
- Version and release-tags: Package version should obviously follow
upstream version in normal, sane cases but especially things like 1.0- pre1 need special rules to handle without epochs, those should be covered in this doc. The old fedora.us packaging guidelines doc, section C-3 (http://www.fedora.us/wiki/PackageNamingGuidelines) pretty much covers these cases if you drop the 0.fdr tags from the rules.
+1. This will help avoid unnecessary epoch inflation. For even more giggles, see development:
rpm -qp --qf='%{epoch}\n' *.rpm | sort | uniq -c | sort -n
- While at versions and releases: can we *please* have a standard on
release-tags. Current FC trees have a wild variety of things in there like "3jpp_2fc", in general a truly random FC3 vs fc2 dist-tags for some packages (disttags are just fine when needed but can we standardize on lowercase like with package names, please :) .. and so on. Just do 'rpm -qp --qf "%{release}\n" *|sort -u' on current FC-devel RPMS directory for giggles. Please let's have a standard of allowed characters in release and version tags as well since we're having one for names?
+1
- Addon packages: when a package is renamed, eg 'adodb' -> 'php-adodb'
it *might* be a good idea to add the original name as a "Provides: adodb" so people looking for upstream naming can find it more easily.
Already covered in section 1.7 "Renaming a package". You need the Obsoletes: too.
On Wed, 2005-02-23 at 23:17 +0200, Panu Matilainen wrote:
Some comments after a quick read-through:
- Version and release-tags: Package version should obviously follow
upstream version in normal, sane cases but especially things like 1.0- pre1 need special rules to handle without epochs, those should be covered in this doc. The old fedora.us packaging guidelines doc, section C-3 (http://www.fedora.us/wiki/PackageNamingGuidelines) pretty much covers these cases if you drop the 0.fdr tags from the rules.
The old C-3 section seemed sane, so I dropped the 0.fdr tagging, cleaned up the rules a bit, and included them.
- While at versions and releases: can we *please* have a standard on
release-tags. Current FC trees have a wild variety of things in there like "3jpp_2fc", in general a truly random FC3 vs fc2 dist-tags for some packages (disttags are just fine when needed but can we standardize on lowercase like with package names, please :) .. and so on. Just do 'rpm -qp --qf "%{release}\n" *|sort -u' on current FC-devel RPMS directory for giggles. Please let's have a standard of allowed characters in release and version tags as well since we're having one for names?
Does the current release standard seem sane? Numeric incrementals, starting at 1, with the exception case of packages having non-numeric versions?
That way, it keeps all the junk out of the Release field, and any non-numeric characters that do appear are there for a valid reason.
- Addon packages: when a package is renamed, eg 'adodb' -> 'php-adodb'
it *might* be a good idea to add the original name as a "Provides: adodb" so people looking for upstream naming can find it more easily.
The "Renaming a Package" section covers this.
Oh and FWIW current rawhide contains quite a few packages other than pam_ and SDL_ with underscores in the name (see below). Of these the various apache mod_foo packages are numerous enough to warrant an exception rule of their own, others should perhaps be renamed?
Added Apache httpd to the pam/SDL rule, added a "packages with locales" rule, and added an "upstream name uses underscore" rule.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Wed, 23 Feb 2005, Tom 'spot' Callaway wrote:
On Wed, 2005-02-23 at 23:17 +0200, Panu Matilainen wrote:
Some comments after a quick read-through:
- Version and release-tags: Package version should obviously follow
upstream version in normal, sane cases but especially things like 1.0- pre1 need special rules to handle without epochs, those should be covered in this doc. The old fedora.us packaging guidelines doc, section C-3 (http://www.fedora.us/wiki/PackageNamingGuidelines) pretty much covers these cases if you drop the 0.fdr tags from the rules.
The old C-3 section seemed sane, so I dropped the 0.fdr tagging, cleaned up the rules a bit, and included them.
Thanks, looks good. One thing which is open to discussion I think is post-release non-numeric versions like 1.0 -> 1.0a where the 'a' doesn't *have* to move to release tag from rpm's POV. I don't mind either way, perhaps it's best to KISS (like the current draft has) and simply move *all* non-numeric bits to release instead of having separate cases for pre- and post-releases.
- While at versions and releases: can we *please* have a standard on
release-tags. Current FC trees have a wild variety of things in there like "3jpp_2fc", in general a truly random FC3 vs fc2 dist-tags for some packages (disttags are just fine when needed but can we standardize on lowercase like with package names, please :) .. and so on. Just do 'rpm -qp --qf "%{release}\n" *|sort -u' on current FC-devel RPMS directory for giggles. Please let's have a standard of allowed characters in release and version tags as well since we're having one for names?
Does the current release standard seem sane? Numeric incrementals, starting at 1, with the exception case of packages having non-numeric versions?
That way, it keeps all the junk out of the Release field, and any non-numeric characters that do appear are there for a valid reason.
Yes, it does look sane and the examples are nice and clean. What's missing IMHO is statement outside examples that the different parts (where necessary) in release tag should be separated with dots, not underscores or other creative items and letters should be lowercase wherever possible.
- Addon packages: when a package is renamed, eg 'adodb' -> 'php-adodb'
it *might* be a good idea to add the original name as a "Provides: adodb" so people looking for upstream naming can find it more easily.
The "Renaming a Package" section covers this.
Mm, yep, indeed.
On the subject of renaming: shouldn't the Provides and Obsoletes be versioned there? There have been some examples in the past where an unversioned obsoletes has caused grief (obsolete-loops causing packages flip-floping) in the past...
Oh and FWIW current rawhide contains quite a few packages other than pam_ and SDL_ with underscores in the name (see below). Of these the various apache mod_foo packages are numerous enough to warrant an exception rule of their own, others should perhaps be renamed?
Added Apache httpd to the pam/SDL rule, added a "packages with locales" rule, and added an "upstream name uses underscore" rule.
Ok. So far looking nice and clean :)
- Panu -
Panu Matilainen wrote :
Thanks, looks good. One thing which is open to discussion I think is post-release non-numeric versions like 1.0 -> 1.0a where the 'a' doesn't *have* to move to release tag from rpm's POV. I don't mind either way, perhaps it's best to KISS (like the current draft has) and simply move *all* non-numeric bits to release instead of having separate cases for pre- and post-releases.
Same here... the gkrellm post-release example where the "a" is moved to the release doesn't seem necessary to me, as it'll go incrementing. Pretty much like 1.0 -> 1.0pl1 -> 1.1 which won't cause any trouble.
But I think I'm merely pointing this out as RH/FC has always left post-release version tags like these in the version... and like Panu, I'm not against the change, especially since it's now so well documented ;-)
Great work Spot! (and those who wrote the original bits too)
Matthias
On Thu, 2005-02-24 at 11:35 +0100, Matthias Saou wrote:
Panu Matilainen wrote :
Thanks, looks good. One thing which is open to discussion I think is post-release non-numeric versions like 1.0 -> 1.0a where the 'a' doesn't *have* to move to release tag from rpm's POV. I don't mind either way, perhaps it's best to KISS (like the current draft has) and simply move *all* non-numeric bits to release instead of having separate cases for pre- and post-releases.
Same here... the gkrellm post-release example where the "a" is moved to the release doesn't seem necessary to me, as it'll go incrementing. Pretty much like 1.0 -> 1.0pl1 -> 1.1 which won't cause any trouble.
Doing it the way I've documented makes it less likely that we'll hit the need for Epoch in a lot of cases. And the cases like gkrellm fit in nicely enough both ways so it can't hurt to standardize it in the non-numeric release case for packagers that are new (or just confused).
Basically, I think the documented method is the simplest method. Hopefully, the Fedora Core folks will see it that way as well, but if not, we'll manage somehow. ;)
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Wed, 23 Feb 2005, Tom 'spot' Callaway wrote:
Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers.
http://fedoraproject.org/wiki/PackageNamingGuidelines
Feedback is welcome, and encouraged.
Looks good, I would propose a standard SPEC file (in the SRPM) formatted as:
%{name}-%{version}-%{release}-%{repotag}.spec
If your working on a SPEC file and install several other versions, this would prevent SPEC files replacing others. And the origin is clear too.
It's something the buildsystem could do before creating the SRPM (in that respect it may not be that important for FE).
For the package release, it may be useful to use < 1 release numbers to indicate a work in progress. (0.1, 0.2) We're doing the same in case we consider something a beta or rc product. (Especially if you're posting incremental test releases for other people to try). The version is always numeric, the release is also always numeric (in case of alpha/beta/rc < 1 and followed by the non numeric portion of the version) postfixed with the disttag and repotag.
PS I like the gnome-applet-%{name} convention, I have too many applets now using the upstream name, which is not very clear whether it is a gnome applet or not.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Wed, Feb 23, 2005 at 11:09:38PM +0100, Dag Wieers wrote:
Looks good, I would propose a standard SPEC file (in the SRPM) formatted as:
%{name}-%{version}-%{release}-%{repotag}.spec
-1. It is easier to deal with shorter spec names that match the package %{name} and hence the name in CVS.
If your working on a SPEC file and install several other versions, this would prevent SPEC files replacing others. And the origin is clear too.
The origin is already clear from the contents of the spec file... If you are worried about overwriting spec files from multiple versions, then you should also be worried about overwriting sources and patches...
You can already prevent these problems with a suitable .rpmmacros file:
%_topdir /home/cra/src/redhat %_ntopdir %{_topdir}/%{name}-%{version}-%{release} %_builddir %{_ntopdir} %_sourcedir %{_ntopdir} %_specdir %{_ntopdir} %_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm %_rpmdir %{_topdir}/RPMS %_srcrpmdir %{_topdir}/SRPMS
It's something the buildsystem could do before creating the SRPM (in that respect it may not be that important for FE).
For the package release, it may be useful to use < 1 release numbers to indicate a work in progress. (0.1, 0.2) We're doing the same in case we consider something a beta or rc product. (Especially if you're posting incremental test releases for other people to try). The version is always numeric, the release is also always numeric (in case of alpha/beta/rc < 1 and followed by the non numeric portion of the version) postfixed with the disttag and repotag.
+1 This goes along with the old fedora.us guidelines for versioning of alpha/beta/rc releases.
On Wed, 23 Feb 2005, Chuck R. Anderson wrote:
On Wed, Feb 23, 2005 at 11:09:38PM +0100, Dag Wieers wrote:
Looks good, I would propose a standard SPEC file (in the SRPM) formatted as:
%{name}-%{version}-%{release}-%{repotag}.spec
-1. It is easier to deal with shorter spec names that match the package %{name} and hence the name in CVS.
In what sense ? As you have to rename the SPEC files yourself in between installs (or change .rpmmacros). For ordinary users fixing something (those that contribute and I want to stimulate contributing :)) having identifiable SPEC filenames is more important than a short filename.
If your working on a SPEC file and install several other versions, this would prevent SPEC files replacing others. And the origin is clear too.
The origin is already clear from the contents of the spec file... If you are worried about overwriting spec files from multiple versions, then you should also be worried about overwriting sources and patches...
In fact, I have a seperate environment for everything my buildsystem does and what I install from other sources. So I'm not that worried about replaced source files because I do not use them directly.
However I often have several SPEC files from several SRPMs installed and if they're all being called the same I have to manually intervene to correct that. (With CVS access to FE this may be less of a problem for FE, but still...)
You can already prevent these problems with a suitable .rpmmacros file:
%_topdir /home/cra/src/redhat %_ntopdir %{_topdir}/%{name}-%{version}-%{release} %_builddir %{_ntopdir} %_sourcedir %{_ntopdir} %_specdir %{_ntopdir} %_rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm %_rpmdir %{_topdir}/RPMS %_srcrpmdir %{_topdir}/SRPMS
The difference is that this has to be manually configured and 'unique' SPEC files is something users will enjoy without configuration. And SRPMs in the end will be more used by end-users (like I am when looking at other's people work) than by the packagers themselves.
Additionally having to use differently versioned directories to diff 2 SPEC files is more annoying than diffing 2 versioned filenames in the same directory.
So I prefer the latter, not that it's that important.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Wed, 2005-02-23 at 23:09 +0100, Dag Wieers wrote:
On Wed, 23 Feb 2005, Tom 'spot' Callaway wrote:
Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers.
http://fedoraproject.org/wiki/PackageNamingGuidelines
Feedback is welcome, and encouraged.
Looks good, I would propose a standard SPEC file (in the SRPM) formatted as:
%{name}-%{version}-%{release}-%{repotag}.spec
If your working on a SPEC file and install several other versions, this would prevent SPEC files replacing others. And the origin is clear too.
Eek, please lets don't. That's what CVS and distro brances of packages are for.
For the package release, it may be useful to use < 1 release numbers to indicate a work in progress. (0.1, 0.2) We're doing the same in case we consider something a beta or rc product. (Especially if you're posting incremental test releases for other people to try).
Yep - this should be covered in the old fedora.us naming standard doc I mentioned but certainly should be explained in the standard.
- Panu -
On Thu, 24 Feb 2005, Panu Matilainen wrote:
On Wed, 2005-02-23 at 23:09 +0100, Dag Wieers wrote:
On Wed, 23 Feb 2005, Tom 'spot' Callaway wrote:
Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers.
http://fedoraproject.org/wiki/PackageNamingGuidelines
Feedback is welcome, and encouraged.
Looks good, I would propose a standard SPEC file (in the SRPM) formatted as:
%{name}-%{version}-%{release}-%{repotag}.spec
If your working on a SPEC file and install several other versions, this would prevent SPEC files replacing others. And the origin is clear too.
Eek, please lets don't. That's what CVS and distro brances of packages are for.
How does that affect SPEC files in SRPMs ? Afaik FE (and RH) SRPMs have a %{name}.spec files inside the SRPM which are not distinguishable. Even when FE or RH is using CVS and distro branches.
I'm talking about renaming the SPEC file to something more identifiable as %{name}.spec before creating the SRPM. Nothing else. DAR is doing this as part of the pre-processing stage of the SPEC file.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Thu, 24 Feb 2005, Dag Wieers wrote:
On Thu, 24 Feb 2005, Panu Matilainen wrote:
Feedback is welcome, and encouraged.
Looks good, I would propose a standard SPEC file (in the SRPM) formatted as:
%{name}-%{version}-%{release}-%{repotag}.spec
If your working on a SPEC file and install several other versions, this would prevent SPEC files replacing others. And the origin is clear too.
Eek, please lets don't. That's what CVS and distro brances of packages are for.
How does that affect SPEC files in SRPMs ? Afaik FE (and RH) SRPMs have a %{name}.spec files inside the SRPM which are not distinguishable. Even when FE or RH is using CVS and distro branches.
I'm talking about renaming the SPEC file to something more identifiable as %{name}.spec before creating the SRPM. Nothing else. DAR is doing this as part of the pre-processing stage of the SPEC file.
I just don't think that renaming spec to some awfully long name buys you any safety at all and only looks ugly as hell :) The SRPM can contain other bits (patches, sources) which overwrite one another when working with several versions of the package in a "normal" rpm build tree.
- Panu -
On Thu, 2005-02-24 at 09:43 +0200, Panu Matilainen wrote:
I just don't think that renaming spec to some awfully long name buys you any safety at all and only looks ugly as hell :) The SRPM can contain other bits (patches, sources) which overwrite one another when working with several versions of the package in a "normal" rpm build tree.
Seconded.
The idea of disttag is not present in the Naming Policy right now, but I think there is good reason to standardize how it should be used in Fedora Extras.
In the event that a single spec file is used for multiple versions of Fedora Extras, it is feasible that two packages with identical "%{name}-%{version}-%{release}" values could exist. This could lead to confusion, especially since their contents provide the same application, merely compiled and linked for different environments and userlands.
In this case, a %{disttag} is needed to differentiate between these two packages, in the Release: field.
The %{disttag} value should be determined from the build-environment. Using redhat-release for this purpose seems like the sanest method. With this command, we can determine the version of the Red Hat/Fedora distribution present in the build-environment:
rpm -q --qf "%{version}\n" `rpm -qf /etc/redhat-release`
The following chart presents the results:
RHL 7.3: 7.3 RHL 8: 8.0 RHL 9: 9 RHEL 2.1 AS: 2.1AS RHEL 2.1 ES: 2.1ES RHEL 2.1 WS: 2.1WS RHEL 2.1 AW: 2.1AW RHEL 3 AS: 3AS RHEL 3 ES: 3ES RHEL 3 WS: 3WS RHEL 3 Desktop: 3Desktop RHEL 4 AS: 4AS RHEL 4 ES: 4ES RHEL 4 WS: 4WS RHEL 4 Desktop: 4Desktop FC-1: 1 FC-2: 2 FC-3: 3
Now, in theory, we would have a problem with Fedora Core and Red Hat Linux release versions overlapping, but hopefully, by the time Fedora Core 9 is current, there will be few remaining users of Red Hat Linux 9.
A bigger problem is dealing with the overlap of RHEL and Fedora Core releases.
The following rpmmacros aren't terribly pretty, but they do work.
%disttaglong %{expand:%%(rpm -qi `rpm -qf /etc/redhat-release` |grep Version | cut -d ":" -f 2 | cut -d " " -f 2 | perl -pe 's/^\s+//')} %rheldisttag %{expand:%%(echo %{disttaglong} | sed -e 's/[^0-9.]//g' -e 's/^/EL/')} %rhldisttag %{expand:%%(echo %{disttaglong} | sed -e 's/^/RH/')} %fcdisttag %{expand:%%(echo %{disttaglong} | sed -e 's/^/FC/')} %disttag %{expand:%%(if echo %{disttaglong} | grep "[^0-9.]"
/dev/null; then \
echo %{rheldisttag} \ else \ case "%{disttaglong}" in \ ( "6.2" | "7.0" | "7.1" | "7.2" | "7.3" | "8.0" | "9" ) \ echo %{rhldisttag} \ ;; \ ( "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" ) \ echo %{fcdisttag} \ ;; \ esac; \ fi;)}
With macros like these, it is then possible to use %{disttag} in the spec to allow a single spec file to be used for multiple versions of Fedora (and outside of Fedora Extras, for RHEL and RHL).
Maintainers would not be required to use %{disttag}. However, should they choose to do so, it should be placed at the end of the release field, preceeded by a period, e.g. Release: 1.%{disttag}.
%{disttag} should never be hardcoded in a spec, it will be assigned by the buildsystem based on the version of the package owning /etc/redhat-release.
Feedback, thoughts, and macro improvements welcome.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Thu, 2005-02-24 at 17:28 -0600, Tom 'spot' Callaway wrote:
With macros like these, it is then possible to use %{disttag} in the spec to allow a single spec file to be used for multiple versions of Fedora (and outside of Fedora Extras, for RHEL and RHL).
Addendum:
The %{disttag} values would be:
RH6.2, RH7.0, RH7.1, RH7.2, RH7.3, RH8.0, RH9 EL2.1, EL3, EL4 FC1, FC2, FC3, FC4, ...
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Thu, 24 Feb 2005, Tom 'spot' Callaway wrote:
On Thu, 2005-02-24 at 17:28 -0600, Tom 'spot' Callaway wrote:
With macros like these, it is then possible to use %{disttag} in the spec to allow a single spec file to be used for multiple versions of Fedora (and outside of Fedora Extras, for RHEL and RHL).
Addendum:
The %{disttag} values would be:
RH6.2, RH7.0, RH7.1, RH7.2, RH7.3, RH8.0, RH9 EL2.1, EL3, EL4 FC1, FC2, FC3, FC4, ...
With the high probability of being flamed again, RPMforge settled for:
0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 < 2.fc4 < 2.fc5
with the advantage of having an upgrade path between EL and FC. I know it's controversial but at least if fulfills an important goal (even though Red Hat does not support upgrades between Fedora and Enterprise).
In the past one of the problems was that RH > FC and therefor RH9 packages would be newer than FC1 packages. The current scheme makes us independant of whatever new name will be given by marketing if we are somewhere in 2008.
There is a known catch here with this scheme (numeric part of disttag in release part).
Disttags are never part of the SPEC file in our case but the pre-processing of the SPEC file before building makes sure it is there when it is needed.
We also have a special disttag '0' to indicate a distribution-agnostic package. Which we mainly use for big packages (artwork, game data, ...).
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Fri, 2005-02-25 at 00:49 +0100, Dag Wieers wrote:
With the high probability of being flamed again, RPMforge settled for:
0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 < 2.fc4 < 2.fc5
with the advantage of having an upgrade path between EL and FC. I know it's controversial but at least if fulfills an important goal (even though Red Hat does not support upgrades between Fedora and Enterprise).
The very topic is outside of the scope of Fedora Extras, however, no one is trying to make life harder for anyone upgrading between Fedora and Enterprise (their life is painful enough).
I'm not opposed to it. Would you be willing to try and modify the macros I posted earlier to fit that schema?
Disttags are never part of the SPEC file in our case but the pre-processing of the SPEC file before building makes sure it is there when it is needed.
The goal of the macros is to have %{disttag} defined by the build environment, and thus, always be correct, rather than having to pass a value to the spec for some packages that use it, since some packages won't.
We also have a special disttag '0' to indicate a distribution-agnostic package. Which we mainly use for big packages (artwork, game data, ...).
IMHO, these packages don't need a disttag at all if they're truly distribution agnostic.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Thu, 2005-02-24 at 18:16 -0600, Tom 'spot' Callaway wrote:
On Fri, 2005-02-25 at 00:49 +0100, Dag Wieers wrote:
With the high probability of being flamed again, RPMforge settled for:
0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 < 2.fc4 < 2.fc5
I'm not opposed to it. Would you be willing to try and modify the macros I posted earlier to fit that schema?
OK. Here is a way to make the macros fit that schema:
# Disttag macros (you really only want to use %{disttag}) # When we get to Fedora Core 6, we'll need to revisit this.
%disttaglong %{expand:%%(rpm -qi `rpm -qf /etc/redhat-release` |grep Version | cut -d ":" -f 2 | cut -d " " -f 2 | perl -pe 's/^\s+//')} %rheldisttag %{expand:%%(echo %{disttaglong} | sed -e 's/[^0-9.]//g' -e 's/^/el/')} %rhldisttag %{expand:%%(echo %{disttaglong} | cut -d "." -f 1 | sed -e 's/^/rh/')} %fcdisttag %{expand:%%(echo %{disttaglong} | sed -e 's/^/fc/')} %disttag %{expand:%%(if echo %{disttaglong} | grep "[^0-9.]"
/dev/null; then \
case "%{rheldisttag}" in \ ( "el2" ) \ echo 0.%{rheldisttag} \ ;; \ ( "el3" ) \ echo 1.%{rheldisttag} \ ;; \ ( "el4" ) \ echo 2.%{rheldisttag} \ ;; \ ( "el5" ) \ echo 3.%{rheldisttag} \ ;; \ esac; \ else \ case "%{disttaglong}" in \ ( "7.0" | "7.1" | "7.2" | "7.3" | "8" | "9" ) \ echo 0.%{rhldisttag} \ ;; \ ( "1" | "2" | "3" ) \ echo 1.%{fcdisttag} \ ;; \ ("4" | "5" | "6" ) \ echo 2.%{fcdisttag} \ ;; \ esac; \ fi;)}
This changes the valid disttag values to:
0.el2 0.rh7 0.rh8 0.rh9 1.el3 1.fc1 1.fc2 1.fc3 2.el4 2.fc4 2.fc5 2.fc6 3.el5
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
Tom 'spot' Callaway wrote :
%disttaglong %{expand:%%(rpm -qi `rpm -qf /etc/redhat-release` |grep Version | cut -d ":" -f 2 | cut -d " " -f 2 | perl -pe 's/^\s+//')}
Hmm, haven't had enough coffee yet, but is the above just to get the version of the package that contains the redhat-release file!? If so, what about this instead :
%(rpm -qf --qf '%{version}' /etc/redhat-release)
I _must_ be missing something...
Matthias
On Fri, 2005-02-25 at 11:42 +0100, Matthias Saou wrote:
Tom 'spot' Callaway wrote :
%disttaglong %{expand:%%(rpm -qi `rpm -qf /etc/redhat-release` |grep Version | cut -d ":" -f 2 | cut -d " " -f 2 | perl -pe 's/^\s+//')}
Hmm, haven't had enough coffee yet, but is the above just to get the version of the package that contains the redhat-release file!? If so, what about this instead :
%(rpm -qf --qf '%{version}' /etc/redhat-release)
I _must_ be missing something...
You are. We can't use %{version} in the macro, because when its parsed at buildtime, it grabs the %{version} for the package being built, and replaces it before running the command. Hence the ickiness.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Fri, 25 Feb 2005 08:05:23 -0600, Tom 'spot' Callaway wrote:
On Fri, 2005-02-25 at 11:42 +0100, Matthias Saou wrote:
Tom 'spot' Callaway wrote :
%disttaglong %{expand:%%(rpm -qi `rpm -qf /etc/redhat-release` |grep Version | cut -d ":" -f 2 | cut -d " " -f 2 | perl -pe 's/^\s+//')}
Hmm, haven't had enough coffee yet, but is the above just to get the version of the package that contains the redhat-release file!? If so, what about this instead :
%(rpm -qf --qf '%{version}' /etc/redhat-release)
I _must_ be missing something...
You are. We can't use %{version} in the macro, because when its parsed at buildtime, it grabs the %{version} for the package being built, and replaces it before running the command. Hence the ickiness.
%(rpm -qf --qf '%%{version}' /etc/redhat-release)
was used successfully before, e.g. in the fedora.us k3b package (see e.g. Fedora Extras CVS FC-1 branch).
On Sat, 2005-02-26 at 18:33 +0100, Michael Schwendt wrote:
%(rpm -qf --qf '%%{version}' /etc/redhat-release)
Yep. %{VERSION} and %{RPMTAG_VERSION} all work. :)
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Thu, 24 Feb 2005, Tom 'spot' Callaway wrote:
On Fri, 2005-02-25 at 00:49 +0100, Dag Wieers wrote:
With the high probability of being flamed again, RPMforge settled for:
0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 < 2.fc4 < 2.fc5
with the advantage of having an upgrade path between EL and FC. I know it's controversial but at least if fulfills an important goal (even though Red Hat does not support upgrades between Fedora and Enterprise).
The very topic is outside of the scope of Fedora Extras, however, no one is trying to make life harder for anyone upgrading between Fedora and Enterprise (their life is painful enough).
I'm not opposed to it. Would you be willing to try and modify the macros I posted earlier to fit that schema?
Disttags are never part of the SPEC file in our case but the pre-processing of the SPEC file before building makes sure it is there when it is needed.
The goal of the macros is to have %{disttag} defined by the build environment, and thus, always be correct, rather than having to pass a value to the spec for some packages that use it, since some packages won't.
Ok, in my opinion it's better to have every package adore to the disttag for the sole reason that you have a grip on what is upgraded and what isn't. Of course, that's what the Distribution-header can be used for (if Red Hat starts using it ! :))
On the other hand the Distribution-header does not make up for unique filenames, which I think is in favor of mandatory disttags. (Although filenames could be renamed to reflect the disttag, without 'polluting' the release-tag).
Previous threads have touched the same subject with all the different opinions attached to it :)
PS Another reason why we do not have the disttag inside a macro is because the SRPMs are distribution agnostic too. If the 'dot' is part of the macro and the macro is void when building the SRPM you can achieve the same result. But a single rpmbuild --rebuild will no longer be sufficient, unless you rewrite the SPEC file and define the voided disttag. If you do that, you might as well pre-process the SPEC file before building anyway.
We also have a special disttag '0' to indicate a distribution-agnostic package. Which we mainly use for big packages (artwork, game data, ...).
IMHO, these packages don't need a disttag at all if they're truly distribution agnostic.
I agree, but on the other hand, tools should be able to tell (by using globs) what packages are distribution agnostic, and a single '0' is something you can more easily glob onto, than the absence of any disttag.
I know this is not the best reason to have '0', but checking each file to see if it does not have the disttag (out of a list of disttags) is much harder than just looking of there is a '0' before the repotag.
eg. ln -sf packages/*/*.0.$repotag.$arch.rpm redhat/el3/$arch/$repotag/
And the '0' is harmless.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Dag Wieers wrote:
On the other hand the Distribution-header does not make up for unique filenames, which I think is in favor of mandatory disttags. (Although filenames could be renamed to reflect the disttag, without 'polluting' the release-tag).
Do you mean something like this:
%{name}-%{version}-%{release}.%{disttag}.%{arch}.rpm
.. where %{disttag} is _not_ an overloaded part of the "Release:" but rather a distinct entity derived from build environment - a bit like %{arch} perhaps with a tag to hard wire it in the spec if required, say "DistTag: any" for agnostic (I'm creating a new RPM tag in this example rather than changing the semantics of "Distribution:").
This would relate well to my previous suggestion where %{disttag} would not be evaluated as part of the release on version comparisons but rather prior to the epoch: %{disttag}:%{epoch}:%{version}-%{release} (hmm, maybe after the epoch would be better?).
Carwyn
On Fri, 25 Feb 2005, Carwyn Edwards wrote:
Dag Wieers wrote:
On the other hand the Distribution-header does not make up for unique filenames, which I think is in favor of mandatory disttags. (Although filenames could be renamed to reflect the disttag, without 'polluting' the release-tag).
Do you mean something like this:
%{name}-%{version}-%{release}.%{disttag}.%{arch}.rpm
.. where %{disttag} is _not_ an overloaded part of the "Release:" but rather a distinct entity derived from build environment - a bit like %{arch} perhaps with a tag to hard wire it in the spec if required, say "DistTag: any" for agnostic (I'm creating a new RPM tag in this example rather than changing the semantics of "Distribution:").
This would relate well to my previous suggestion where %{disttag} would not be evaluated as part of the release on version comparisons but rather prior to the epoch: %{disttag}:%{epoch}:%{version}-%{release} (hmm, maybe after the epoch would be better?).
The problem with such a scheme of course is that it requires a change to RPM (and all RPM related tools), and for that reason alone is not backward compatible.
If you want packages from a certain distribution (or repo) to have a higher priority than other packages disregarding the EVR (or VR). I think that functionality is best put into Yum, Apt, Smart or up2date. Because they understand the notion of repositories.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Dag Wieers wrote:
The problem with such a scheme of course is that it requires a change to RPM (and all RPM related tools),
I know, I know - I'm more thinking ahead to when the tag mangling goes away :-)
In the meantime, the current direction of the package naming looks good. So far it's letting me define a local naming policy of:
%{name}-%{verison}-%{release}.%{local_release}.%{repo}
Where: %{release}: Upstream release version if it exists otherwise |0| (zero). %{local_release}: Local release version that adheres to the same rules as the Fedora release field if %{release} is 0, otherwise use a single integer. %{repo}: Local repo tag.
I suspect that many Fedora users have their own local repos (maybe not as big as FreshRPMs or Dag :-) ) and being able to define a naming policy that works with upstream is a good thing. A common example of what we need to do is to patch Fedora rpms with things that haven't been integrated yet or to add some feature to the build options.
Carwyn
On Thu, 24 Feb 2005, Tom 'spot' Callaway wrote:
On Fri, 2005-02-25 at 00:49 +0100, Dag Wieers wrote:
With the high probability of being flamed again, RPMforge settled for:
0.el2 < 0.rh7 < 0.rh8 < 0.rh9 < 1.el3 < 1.fc1 < 1.fc2 < 1.fc3 < 2.el4 < 2.fc4 < 2.fc5
with the advantage of having an upgrade path between EL and FC. I know it's controversial but at least if fulfills an important goal (even though Red Hat does not support upgrades between Fedora and Enterprise).
The very topic is outside of the scope of Fedora Extras, however, no one is trying to make life harder for anyone upgrading between Fedora and Enterprise (their life is painful enough).
I don't see why we should add cruft to our release tags to help people shoot their own feet either. I'm not going to start flamewar over this - there are worse things in life that RPMforge disttags :) but I simply don't see no value added whatsoever by trying to create an upgrade path for *extras* when one doesn't exist for the actual products.
- Panu -
I don't see why we should add cruft to our release tags to help people shoot their own feet either. I'm not going to start flamewar over this - there are worse things in life that RPMforge disttags :) but I simply don't see no value added whatsoever by trying to create an upgrade path for *extras* when one doesn't exist for the actual products.
+1 -sv
On Fri, 2005-02-25 at 15:26 +0200, Panu Matilainen wrote:
I don't see why we should add cruft to our release tags to help people shoot their own feet either. I'm not going to start flamewar over this - there are worse things in life that RPMforge disttags :) but I simply don't see no value added whatsoever by trying to create an upgrade path for *extras* when one doesn't exist for the actual products.
Here's the point: Its not mandatory. If you're not trying to work the "single spec/multiple Fedoras" case, then don't use it.
The standard will make that very clear.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Fri, 25 Feb 2005, Tom 'spot' Callaway wrote:
On Fri, 2005-02-25 at 15:26 +0200, Panu Matilainen wrote:
I don't see why we should add cruft to our release tags to help people shoot their own feet either. I'm not going to start flamewar over this - there are worse things in life that RPMforge disttags :) but I simply don't see no value added whatsoever by trying to create an upgrade path for *extras* when one doesn't exist for the actual products.
Here's the point: Its not mandatory. If you're not trying to work the "single spec/multiple Fedoras" case, then don't use it.
The standard will make that very clear.
In case I wasn't clear: I'm not complaining about disttags at all, they're useful in many cases. What I'm complaining about is the IMHO silly extra stuff in the release tag for providing an upgrade path between products which aren't upgradable in reality. Plain fc3, fc4, el4 etc as disttags are perfectly fine by me.
- Panu -
Tom 'spot' Callaway wrote:
In the event that a single spec file is used for multiple versions of Fedora Extras, it is feasible that two packages with identical "%{name}-%{version}-%{release}" values could exist.
This is going on a tanget I admit but .. looking forwards couldn't RPM be taught to use a specific DistTag: tag for this. RPM version comparisons could then be based on something like %{disttag}:%{epoch}:%{version}-%{release} (%{disttag} == 0 signifying a dist agnostic package). Rpmbuild could even implicitly set this using a disttag macro like the one you suggest.
To keep overloading the Release: tag with more implicit information seems wrong.
Carwyn
Tom 'spot' Callaway wrote :
Maintainers would not be required to use %{disttag}. However, should they choose to do so, it should be placed at the end of the release field, preceeded by a period, e.g. Release: 1.%{disttag}.
%{disttag} should never be hardcoded in a spec, it will be assigned by the buildsystem based on the version of the package owning /etc/redhat-release.
Feedback, thoughts, and macro improvements welcome.
I'm a bit confused... you mean that initial spec files will contain this %{disttag} but that the final one in the source rpm will contain the hardcoded value instead? This will produce quite a lot of confusion for "quick rebuilds" of source packages with hardcoded releases on other distributions... and I don't really understand why we want to use rpm and macros for this whole substitution if mangling of the spec gets done in the end.
An easy to way to fix this would be to have "%{?disttag}" appended to the "Release:" line of the spec by the build system, and have the "." returned by the macro (or use a longer "%{?disttag:.%{disttag}}"). That way, when disttag is defined (by a newer redhat-rpm-config for instance) it'll be expanded for the build, but if it isn't, the build will still work with no changes and produce a package with a simple integer release tag.
More thoughts?
Matthias
On Fri, 2005-02-25 at 11:55 +0100, Matthias Saou wrote:
An easy to way to fix this would be to have "%{?disttag}" appended to the "Release:" line of the spec by the build system, and have the "." returned by the macro (or use a longer "%{?disttag:.%{disttag}}"). That way, when disttag is defined (by a newer redhat-rpm-config for instance) it'll be expanded for the build, but if it isn't, the build will still work with no changes and produce a package with a simple integer release tag.
This is what I meant, but you said it better than I did.
I prefer the %{?disttag:.%{disttag}} syntax for use, if for no other reason than it makes the macro a little cleaner.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
"Tom 'spot' Callaway" tcallawa@redhat.com writes:
An easy to way to fix this would be to have "%{?disttag}" appended to the "Release:" line of the spec by the build system, and have the "." returned by the macro
... I prefer the %{?disttag:.%{disttag}} syntax for use, if for no other reason than it makes the macro a little cleaner.
IMO, the opposite it true... defining the macro happens once at a central place invisible for most people, but it will be used in hundreds of .spec files (perhaps). So I would prefer a clear and simple usage.
Enrico
On Tue, 2005-03-01 at 03:01 +0100, Enrico Scholz wrote:
"Tom 'spot' Callaway" tcallawa@redhat.com writes:
An easy to way to fix this would be to have "%{?disttag}" appended to the "Release:" line of the spec by the build system, and have the "." returned by the macro
... I prefer the %{?disttag:.%{disttag}} syntax for use, if for no other reason than it makes the macro a little cleaner.
IMO, the opposite it true... defining the macro happens once at a central place invisible for most people, but it will be used in hundreds of .spec files (perhaps). So I would prefer a clear and simple usage.
This is really semantics.
Its either: We use %{?disttag:.%{disttag}} in the Release: field, and we conditionalize like this: %if "%{disttag}" == "2.fc3"
Or, we use %{?disttag:%{disttag}} in the Release: field, and we conditionalize like this: %if "%{disttag}" == ".2.fc3"
It doesn't matter to me. I'd prefer the extra period in the Release field with the simplified conditionals, but if everyone else prefers the other way around, then I'll document the other way.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Mon, 28 Feb 2005 21:29:26 -0600, Tom 'spot' Callaway wrote:
Its either: We use %{?disttag:.%{disttag}} in the Release: field, and we conditionalize like this: %if "%{disttag}" == "2.fc3"
Or, we use %{?disttag:%{disttag}} in the Release: field, and we conditionalize like this: %if "%{disttag}" == ".2.fc3"
I hope we never conditionalise like that, where we must look up weird dist tags in a table, because we don't have an easier way how to determine the actual build target platform conditionally.
If we go as far as evaluating %{disttag} instead of keeping it fully optional -- %{?disttag:...} means it can be undefined (!) -- we better define an unambiguous %{dist} or %{distribution} constant somewhere.
It doesn't matter to me. I'd prefer the extra period in the Release field with the simplified conditionals, but if everyone else prefers the other way around, then I'll document the other way.
+1 to Enrico's view. A simple and clean %{?disttag} appended to the release field. And since it can expand to virtually everything, don't abuse it for conditionally _guessing_ build platforms.
On Tue, 2005-03-01 at 05:56 +0100, Michael Schwendt wrote:
It doesn't matter to me. I'd prefer the extra period in the Release field with the simplified conditionals, but if everyone else prefers the other way around, then I'll document the other way.
+1 to Enrico's view. A simple and clean %{?disttag} appended to the release field. And since it can expand to virtually everything, don't abuse it for conditionally _guessing_ build platforms.
Let me reiterate. I am fundamentally opposed to a disttag that can "expand to virtually everything". Hence, the macro definition of disttag, and the limitation of the defined possiblities.
With the macro, we're not guessing the build platform. redhat-release shouldn't lie in our buildroots, or we have bigger problems.
I vastly oversimplified the conditional cases, obviously, when used, they should be checked for disttag existence first.
But I do see the value of %{?disttag} in the release field now, thanks.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Mar 1 mars 2005 14:41, Tom 'spot' Callaway a écrit :
On Tue, 2005-03-01 at 05:56 +0100, Michael Schwendt wrote:
It doesn't matter to me. I'd prefer the extra period in the Release field with the simplified conditionals, but if everyone else prefers the other way around, then I'll document the other way.
+1 to Enrico's view. A simple and clean %{?disttag} appended to the release field. And since it can expand to virtually everything, don't abuse it for conditionally _guessing_ build platforms.
Let me reiterate. I am fundamentally opposed to a disttag that can "expand to virtually everything". Hence, the macro definition of disttag, and the limitation of the defined possiblities.
In this case do the defined possibilities take into account rawhide and test systems ?
Regards,
On Tue, 2005-03-01 at 15:41 +0100, Nicolas Mailhot wrote:
In this case do the defined possibilities take into account rawhide and test systems ?
I tested, and it treats rawhide correctly (labels it as the next release), and I'm pretty sure it will do the same with test releases, since we're grabbing the package %{version} from the *-release package, not trying to parse /etc/redhat-release.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Tue, 01 Mar 2005 07:41:08 -0600, Tom 'spot' Callaway wrote:
Let me reiterate. I am fundamentally opposed to a disttag that can "expand to virtually everything". Hence, the macro definition of disttag, and the limitation of the defined possiblities.
Let me expand on my comment then.
We don't use the disttag for branding, do we? The purpose of appending a disttag to the package release is not in flagging a package file as being for a specific distribution environment. If you disagree, a tag like "2.el4" is a very poor choice.
The purpose of a disttag postfix -- is it the primary or sole purpose? -- is in making it possible that a single src.rpm can be built for multiple distribution releases without needing to worry about EVR comparison for upgrade paths.
Using this disttag postfix is transparent to the packager, except for the %{?disttag} macro that must be appended to the Release value. Whether the postfix will be ".FC2", ".fc3", ".RHEL4" or empty should not be something the package developer needs to worry about. Yes, the macro can be undefined and then would expand to nothing and would append nothing. This would be the case for every build machine which isn't updated to define %disttag somewhere.
Hence I'd like to avoid a multi-purpose macro, which is not only used to append a release postfix, but which is also relied on upon finding out the build target distribution.
The earlier posted dist tag list
0.el2 0.rh7 0.rh8 0.rh9 1.el3 1.fc1 1.fc2 1.fc3 2.el4 2.fc4 2.fc5 2.fc6 3.el5
is enough of a kludge already. An ugly kludge, which pretends an upgrade path which is unsupported, and which makes package file names ugly too. But it would achieve what it's supposed to achieve, provided that every package update is built and released for all newer distro releases.
But please, if we go as far as defining a %disttag value somewhere in our build environments, which is also to be used for determining the target distro in conditional spec sections, better let's define a second macro. A second macro, which has the sole purpose of making it unnecessary to examine redhat-release in the spec file.
That one could be everything from a generic %distribution value to a specific %{?fedora} and %{?rhel}, which expand to a numerical release version. Would also allow much more obvious rpmbuild --define "fedora 4" builds. I'd rather check for "%{?rhel}" == "4" than to check for "%{?disttag}" == ".2.el4".
On Tue, 1 Mar 2005, Michael Schwendt wrote:
On Tue, 01 Mar 2005 07:41:08 -0600, Tom 'spot' Callaway wrote:
Let me reiterate. I am fundamentally opposed to a disttag that can "expand to virtually everything". Hence, the macro definition of disttag, and the limitation of the defined possiblities.
Let me expand on my comment then.
We don't use the disttag for branding, do we? The purpose of appending a disttag to the package release is not in flagging a package file as being for a specific distribution environment. If you disagree, a tag like "2.el4" is a very poor choice.
The purpose of a disttag postfix -- is it the primary or sole purpose? -- is in making it possible that a single src.rpm can be built for multiple distribution releases without needing to worry about EVR comparison for upgrade paths.
Using this disttag postfix is transparent to the packager, except for the %{?disttag} macro that must be appended to the Release value. Whether the postfix will be ".FC2", ".fc3", ".RHEL4" or empty should not be something the package developer needs to worry about. Yes, the macro can be undefined and then would expand to nothing and would append nothing. This would be the case for every build machine which isn't updated to define %disttag somewhere.
Hence I'd like to avoid a multi-purpose macro, which is not only used to append a release postfix, but which is also relied on upon finding out the build target distribution.
The earlier posted dist tag list
0.el2 0.rh7 0.rh8 0.rh9 1.el3 1.fc1 1.fc2 1.fc3 2.el4 2.fc4 2.fc5 2.fc6 3.el5
is enough of a kludge already. An ugly kludge, which pretends an upgrade path which is unsupported, and which makes package file names ugly too. But it would achieve what it's supposed to achieve, provided that every package update is built and released for all newer distro releases.
But please, if we go as far as defining a %disttag value somewhere in our build environments, which is also to be used for determining the target distro in conditional spec sections, better let's define a second macro. A second macro, which has the sole purpose of making it unnecessary to examine redhat-release in the spec file.
That one could be everything from a generic %distribution value to a specific %{?fedora} and %{?rhel}, which expand to a numerical release version. Would also allow much more obvious rpmbuild --define "fedora 4" builds. I'd rather check for "%{?rhel}" == "4" than to check for "%{?disttag}" == ".2.el4".
RPMforge uses %{dist} for providing the release, like:
el2, el3, el4, rh6, rh7, rh8, rh9, fc1, fc2, fc3
We don't have a disttag, because this is appended to the Release-tag by the buildsystem (since the only real reason is to have it in the Release-tag and only in the Release-tag, it does not actually have to be inside the SPEC file anyway). The prefix dot also is no longer required.
This allows us to do things like:
%{?dist: %{expand: %%define %dist 1}} and %{?el2:%define _without_alsa 1} and %if %{?el2:1}%{?el3:1}%{?el4:1}0
Some of these things look ugly, I agree. But since I'm not a developer and a change in RPM is less desired anyway, it's probably the closest we can go if the functionality is required.
I would like to expand the RPM language somehow to allow for constructs like:
%if %{dist} in ('el2', 'el3', 'el4') or %if %{dist} matches '^el'
If new things are added to RPM, we either require a backport to older rpm-build or wait wcs 7 years (el4 eol) to start using the functionality. Something FE does not have to worry about as much as I do though.
So is there a reason why we have to have the disttag and cannot have the buildsystem rewrite the SPEC file ?
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Tue, 1 Mar 2005, Ville Skyttä wrote:
On Tue, 2005-03-01 at 21:55 +0100, Dag Wieers wrote:
%if %{dist} matches '^el'
%if 0%(echo %{dist} | grep -q ^el && echo 1) ...
Well... :) Things should still be somewhat obvious. I'd much rather have:
%if %{?el2} or %{?el3} or %if not %{?el2} and not %{?el3}
than %if %{?el2:1}%{?el3:1}0 or ???
Even though you have much flexibility as you just demonstrated, simplicity is important. Especially if you want to build from a single SPEC file you want to bring down the amount of 'ugly glue'.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Tue, 1 Mar 2005 21:55:57 +0100 (CET), Dag Wieers wrote:
RPMforge uses %{dist} for providing the release, like:
el2, el3, el4, rh6, rh7, rh8, rh9, fc1, fc2, fc3
That's even more reason for Fedora Extras not to use an ugly %disttag for the same purpose. As if RPM's spec syntax were not ugly enough.
On Tue, 2005-03-01 at 16:08 +0100, Michael Schwendt wrote:
The purpose of a disttag postfix -- is it the primary or sole purpose? -- is in making it possible that a single src.rpm can be built for multiple distribution releases without needing to worry about EVR comparison for upgrade paths.
The purpose of a disttag postfix was so that a single src.rpm can be built for multiple distribution releases.
There are cases in which BuildRequires: and Requires: will be different for different distribution releases. Hence, the disttag does double duty:
- it differentiates multiple packages which would otherwise have the same %{name}-%{version}-%{release}, but very different dependencies.
- it allows for a conditional check in the spec to deal with the differing dependencies.
But please, if we go as far as defining a %disttag value somewhere in our build environments, which is also to be used for determining the target distro in conditional spec sections, better let's define a second macro. A second macro, which has the sole purpose of making it unnecessary to examine redhat-release in the spec file.
OK, I agree with this. I don't want to insult RPMForge, but I really don't think that an upgrade path between RHEL and Fedora is viable, or something that we should attempt to promote. I've been thinking about this, and it has two major downsides:
1. It implies we support it. We don't. 2. It adds an extra field to the Release to confuse people. The vast majority of people will understand why a ".fc3" or ".el4" might show up in the %{release} field, they won't understand why there is an .2 vs a .3 in front of the dist.
That one could be everything from a generic %distribution value to a specific %{?fedora} and %{?rhel}, which expand to a numerical release version. Would also allow much more obvious rpmbuild --define "fedora 4" builds. I'd rather check for "%{?rhel}" == "4" than to check for "%{?disttag}" == ".2.el4".
This shouldn't be terribly difficult to do.
Lets say I whip up some macros that define %{rhel}, %{fedora}, and %{rhl}, if they are relevant, with the appropriate numeric version.
What would the conditionals look like?
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Tue, 1 Mar 2005, Tom 'spot' Callaway wrote:
OK, I agree with this. I don't want to insult RPMForge, but I really don't think that an upgrade path between RHEL and Fedora is viable, or something that we should attempt to promote. I've been thinking about this, and it has two major downsides:
- It implies we support it. We don't.
- It adds an extra field to the Release to confuse people.
It would be insulting if you said we were morons for having it :) But as Fedora Extras goal is to limit to Fedora packages only, it makes sense.
Although I do not agree that having it implies you support it per se. You allow it if people want to go there. And people have successfully upgrade from RH 7.3 and RH 9 to RHEL 3, likewise people are upgrading FC to RHEL 4 with only minor adaptations.
Also, with smart package managers (that can prioritize repositories) it might become unnecessary in the future to have it.
If the disttag will only contain 'rh9', 'fc1' or 'el3' and be used for conditionals, can we consider using %{dist} instead of %{disttag} ? This would be compatible with our usage, is shorter and I don't see any drawbacks.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Tue, 01 Mar 2005 19:37:33 -0600, Tom 'spot' Callaway wrote:
Lets say I whip up some macros that define %{rhel}, %{fedora}, and %{rhl}, if they are relevant, with the appropriate numeric version.
What would the conditionals look like?
Examples, assuming %rhel is defined only on Red Hat Enterprise Linux, %fedora is defined only on Fedora Core, %rhl is defined only on Red Hat Linux:
# Do something special for RHEL. %if 0%{?rhel} # ... %endif
# Do something for FC4 and beyond. %if "%fedora" >= "4" # ... %endif
# One-liners, here set a default switch. %{?fedora:%define _with_xfce --with-xfce}
# Logical AND, do something for RHEL and RHL. %if 0%{?rhel} %if 0%{?rhl} # ... %endif %endif
# Logical OR, do something for either RHL or Fedora. %if 0%{?rhl}%{?fedora} # ... %endif
# Safer version, in case %rhl or %fedora expand to something non-numerical. %if 0%{?rhl:1}%{?fedora:1} # ... %endif
# Logical NOT, don't do something for RHEL %if 0%{!?rhel} # ... %endif
rpmbuild --rebuild --define "rhel 3" blubb.src.rpm
On Thu, Feb 24, 2005 at 05:28:38PM -0600, Tom 'spot' Callaway wrote:
rpm -q --qf "%{version}\n" `rpm -qf /etc/redhat-release`
Instead of hard-coding the filename, how about using the Provides: that is in the package?
rpm -q --whatprovides --qf "%{version}\n" redhat-release
On Fri, 2005-02-25 at 10:31 -0500, Chuck R. Anderson wrote:
On Thu, Feb 24, 2005 at 05:28:38PM -0600, Tom 'spot' Callaway wrote:
rpm -q --qf "%{version}\n" `rpm -qf /etc/redhat-release`
Instead of hard-coding the filename, how about using the Provides: that is in the package?
rpm -q --whatprovides --qf "%{version}\n" redhat-release
We can't use "--qf "%{version}\n" in the macro.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Fri, 25 Feb 2005, Tom 'spot' Callaway wrote:
On Fri, 2005-02-25 at 10:31 -0500, Chuck R. Anderson wrote:
On Thu, Feb 24, 2005 at 05:28:38PM -0600, Tom 'spot' Callaway wrote:
rpm -q --qf "%{version}\n" `rpm -qf /etc/redhat-release`
Instead of hard-coding the filename, how about using the Provides: that is in the package?
rpm -q --whatprovides --qf "%{version}\n" redhat-release
We can't use "--qf "%{version}\n" in the macro.
You can use:
rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n'
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Fri, 2005-02-25 at 21:26 +0200, Ville Skyttä wrote:
On Fri, 2005-02-25 at 19:43 +0100, Dag Wieers wrote:
You can use:
rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n'
...or just %{VERSION} (in uppercase).
Ok. New macros:
# Disttag macros (you really only want to use %{disttag}) # When we get to Fedora Core 6, we'll need to revisit this.
%disttaglong %{expand:%%(rpm -qf --qf '%{VERSION}' /etc/redhat-release)} %rheldisttag %{expand:%%(echo %{disttaglong} | sed -e 's/[^0-9.]//g' -e 's/^/el/')} %rhldisttag %{expand:%%(echo %{disttaglong} | cut -d "." -f 1 | sed -e 's/^/rh/')} %fcdisttag %{expand:%%(echo %{disttaglong} | sed -e 's/^/fc/')} %disttag %{expand:%%(if echo %{disttaglong} | grep "[^0-9.]"
/dev/null; then \
case "%{rheldisttag}" in \ ( "el2" ) \ echo 0.%{rheldisttag} \ ;; \ ( "el3" ) \ echo 1.%{rheldisttag} \ ;; \ ( "el4" ) \ echo 2.%{rheldisttag} \ ;; \ ( "el5" ) \ echo 3.%{rheldisttag} \ ;; \ esac; \ else \ case "%{disttaglong}" in \ ( "7.0" | "7.1" | "7.2" | "7.3" | "8" | "9" ) \ echo 0.%{rhldisttag} \ ;; \ ( "1" | "2" | "3" ) \ echo 1.%{fcdisttag} \ ;; \ ("4" | "5" | "6" ) \ echo 2.%{fcdisttag} \ ;; \ esac; \ fi;)}
Is anyone opposed to adopting the %{disttag} methodology as the documented method for supporting single spec files for multiple Fedora distros? If not, I'll start writing it up.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
Tom 'spot' Callaway (tcallawa@redhat.com) said:
On Fri, 2005-02-25 at 21:26 +0200, Ville Skyttä wrote:
On Fri, 2005-02-25 at 19:43 +0100, Dag Wieers wrote:
You can use:
rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n'
...or just %{VERSION} (in uppercase).
Ok. New macros:
So, every package BuildRequires: redhat-release?
Frankly, I think it's somewhat gross. Not that I have better solutions off of the top of my head.
Bill
On Fri, 2005-02-25 at 17:19 -0500, Bill Nottingham wrote:
Tom 'spot' Callaway (tcallawa@redhat.com) said:
On Fri, 2005-02-25 at 21:26 +0200, Ville Skyttä wrote:
On Fri, 2005-02-25 at 19:43 +0100, Dag Wieers wrote:
You can use:
rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n'
...or just %{VERSION} (in uppercase).
Ok. New macros:
So, every package BuildRequires: redhat-release?
Frankly, I think it's somewhat gross. Not that I have better solutions off of the top of my head.
No properly installed system should be missing a package which Provides: redhat-release. This has been true for at least the last 5 years.
If our buildroots don't have it, then thats a serious failure (its in System Environment/Base).
And I don't disagree with your "gross" assessment, but its the least evil solution I could find.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
Tom 'spot' Callaway (tcallawa@redhat.com) said:
If our buildroots don't have it, then thats a serious failure (its in System Environment/Base).
Well, you'd still want it to get pulled in via a dep somehow. Right now that would be via initscripts, which may or may not be in the build dependency chain.
Bill
On Fri, 2005-02-25 at 18:02 -0500, Bill Nottingham wrote:
Tom 'spot' Callaway (tcallawa@redhat.com) said:
If our buildroots don't have it, then thats a serious failure (its in System Environment/Base).
Well, you'd still want it to get pulled in via a dep somehow. Right now that would be via initscripts, which may or may not be in the build dependency chain.
So basically, its not safe to assume any of System Environment/Base is installed?
Should all packages start having bash, coreutils, grep, etc, etc as BuildRequires: ?
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
Tom 'spot' Callaway (tcallawa@redhat.com) said:
On Fri, 2005-02-25 at 18:02 -0500, Bill Nottingham wrote:
Tom 'spot' Callaway (tcallawa@redhat.com) said:
If our buildroots don't have it, then thats a serious failure (its in System Environment/Base).
Well, you'd still want it to get pulled in via a dep somehow. Right now that would be via initscripts, which may or may not be in the build dependency chain.
So basically, its not safe to assume any of System Environment/Base is installed?
Should all packages start having bash, coreutils, grep, etc, etc as BuildRequires: ?
There should be a stock list on the wiki somewhere; you can assume coreutils, gcc, make, etc., and whatever those pull in. Whether or not that means they'd pull in initscripts, I don't know.
Bill
On Fri, 2005-02-25 at 18:20 -0500, Bill Nottingham wrote:
Tom 'spot' Callaway (tcallawa@redhat.com) said:
On Fri, 2005-02-25 at 18:02 -0500, Bill Nottingham wrote:
Tom 'spot' Callaway (tcallawa@redhat.com) said:
If our buildroots don't have it, then thats a serious failure (its in System Environment/Base).
Well, you'd still want it to get pulled in via a dep somehow. Right now that would be via initscripts, which may or may not be in the build dependency chain.
So basically, its not safe to assume any of System Environment/Base is installed?
Should all packages start having bash, coreutils, grep, etc, etc as BuildRequires: ?
There should be a stock list on the wiki somewhere; you can assume coreutils, gcc, make, etc., and whatever those pull in. Whether or not that means they'd pull in initscripts, I don't know.
coreutils requires pam, which requires initscripts. Kevin Bacon is in there somewhere too, but it means we don't need BuildRequires: redhat-release.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Fri, 2005-02-25 at 18:02 -0500, Bill Nottingham wrote:
Tom 'spot' Callaway (tcallawa@redhat.com) said:
If our buildroots don't have it, then thats a serious failure (its in System Environment/Base).
Well, you'd still want it to get pulled in via a dep somehow. Right now that would be via initscripts, which may or may not be in the build dependency chain.
Where are you planning to put these disttag macros anyway? Just document them, or include in some package, eg. redhat-rpm-config? Such a package could carry the necessary dependencies, if any.
On Sat, 2005-02-26 at 10:43 +0200, Ville Skyttä wrote:
On Fri, 2005-02-25 at 18:02 -0500, Bill Nottingham wrote:
Tom 'spot' Callaway (tcallawa@redhat.com) said:
If our buildroots don't have it, then thats a serious failure (its in System Environment/Base).
Well, you'd still want it to get pulled in via a dep somehow. Right now that would be via initscripts, which may or may not be in the build dependency chain.
Where are you planning to put these disttag macros anyway? Just document them, or include in some package, eg. redhat-rpm-config? Such a package could carry the necessary dependencies, if any.
They probably should go in a package, like redhat-rpm-config. Elliot, that's your package, would you be interested in adding these disttag macros into redhat-rpm-config's macros file for FC4?
If so, I'll whip up a patch for you.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Fri, Feb 25, 2005 at 05:19:49PM -0500, Bill Nottingham wrote:
Tom 'spot' Callaway (tcallawa@redhat.com) said:
On Fri, 2005-02-25 at 21:26 +0200, Ville Skyttä wrote:
On Fri, 2005-02-25 at 19:43 +0100, Dag Wieers wrote:
You can use:
rpm -qf /etc/redhat-release --qf '%{RPMTAG_VERSION}\n'
...or just %{VERSION} (in uppercase).
Ok. New macros:
So, every package BuildRequires: redhat-release?
Frankly, I think it's somewhat gross. Not that I have better solutions off of the top of my head.
why have the chrooted system do the guesswork, when the information is there at the rpmbuild level?
rpmbuild --define 'disttag whatever' ...
And if you can convince Jeff to patch up an automated suffix to the rpm tag you could keep the specfile totally clean from disttags, e.g. like they look like today.
The idea has been brought to Jeff, but he thought we were asking for a Disttag tag in the rpm header and implemented this instead.
In fact the best solution would be to have a releasesuffix macro/header tag which rpm automatically tags onto the releasetag, e.g.
rpmbuild -bs --define 'releasesuffix .at' foo.spec
produces the distro agnostic foo-1.2.3-4.at.src.rpm
rpmbuild --rebuild --define 'releasesuffix rhel4.at' foo-1.2.3-4.at.src.rpm
produces foo-1.2.3-4.rhel4.at.i386.rpm
As a side effect the releasesuffix macro/header tag can be used both for disttags as well as for repotags, the latter being just a mark of origin.
On Sat, 2005-02-26 at 10:53 +0100, Axel Thimm wrote:
why have the chrooted system do the guesswork, when the information is there at the rpmbuild level?
rpmbuild --define 'disttag whatever' ...
Because I don't want to overcomplicate the buildsystem, or overuse the disttag.
Let me try and clarify my thoughts here.
I think the "%{release}" field should be as simple as possible. The original goal of the "%{release}" field was so that you could track the difference between a package built yesterday, and today's new build. I realize there are some cases in which people tried to overload the "%{release} field.
These seem to be the three most common:
- Dealing with "pre-release" versions of packages, which screw up the proper ordering of packages, making rpm think that "pre-release" packages are infact newer than the final releases.
- Dealing with a single spec file that builds for multiple versions of Fedora Core/RHL/RHEL.
- Repository tagging a package.
Now, I've looked at these three cases, and I've trying to document the PackageNamingGuidelines to deal with the "pre-release" case (and its still not entirely done, I'm going to move the "post-release" cases back to %{version})
The %{disttag} macros are designed to take the conscious thought out of the build process, so that maintainers in the "single spec" case can use %{?disttag:.%{disttag}} in the "Release:" (and check against %{disttag} in conditionals in the spec) and know that it will work. If you have to pass the value at build time, you're opening the door for failure, and for packagers to pollute the %{release} value.
I'm trying to avoid packages named like this:
logjam-4.4.1-44.0.3.17.FC4_spotwashere_WuTangClan3.i386.rpm
This is what I'm hoping for:
In the primary case (one spec per distro): logjam-4.4.1-44.i386.rpm
In the pre-release case: logjam-4.4.2-0.1.a.i386.rpm
In the multiple-distro/single-spec case:
logjam-4.4.1-44.2.fc4.i386.rpm
In the multiple-distro/single-spec and pre-release case:
logjam-4.4.2-0.1.a.2.fc4.i386.rpm
^^^ That's still ugly, but its the worst possible corner case.
The third reason to overload the %{release} field, repository tagging? I don't see the point of doing it. Fedora Extras certainly doesn't need to do it. It makes the package unnecessarily long and ugly, and it confuses the upgrade progress. Is a package with a repotag of "Aargh" newer than a repotag of "BoOoOo". 99% of users don't care at all where their package comes from, as long as it works.
This is another reason I want %{disttag} to be defined automatically, without anyone trying to --with a different value in there and cluttering up the release field with noise.
And if you can convince Jeff to patch up an automated suffix to the rpm tag you could keep the specfile totally clean from disttags, e.g. like they look like today.
This is a noble long term goal, but I'm trying to avoid patching rpm unless absolutely necessary. The %{disttag} macros are backwards compatible to at least Red Hat Linux 7.3 (is anyone really building for older builds?).
Ideally, it would be a releasesuffix, very much like arch is today. RPM would know about the proper ordering of distributions for upgrades, be able to detect it from the system automatically, and users could enable/disable the use of the releasesuffix disttag from their own ~/.rpmmacros.
But that's an extremely non-trivial process, and I'm not going to dump it on Jeff.
produces foo-1.2.3-4.rhel4.at.i386.rpm
Just to reiterate, I don't think the disttag should be used for repo tagging. I consider the "mark of origin" unnecessary clutter.
In no way am I trying to belittle anyone who has created a repo, they should be proud of their packages, but they shouldn't have to label them like 0-day warez. If a user has edited their yum or apt config to include it, then let that tool identify the origin of the package at install time. I know for a fact that yum does this.
So, let me tell you my selfish utopian goal:
I want everyone packaging their open-source code in Fedora Extras. If everyone with an open-source, US-friendly package was storing them in Fedora Extras, we wouldn't even need repository tagging. It would eliminate a LOT of repository mixing pain. Maintainers would still have control over their package, within reasonable standards and practices.
Fedora Extras would become a one-stop shop for getting packages that are not in Fedora Core. And I for one, would love to see us have RHEL branches in Extras, but in the short-term, I want it to be easy for someone to maintain their spec file and sources in Fedora Extras, and build their RHEL packages from that for their own RHEL repository.
And I'm the unlucky guy who gets to try and make this happen.
Doesn't my utopia sound nice? The best part: We can do it. I'm not so dumb to believe that there will never be other repositories besides Fedora Extras, but the more we can centralize, the less duplication of effort occurs. The more we centralize, the less confusing it is to the Fedora end-user. The third party RPM repositories are doing good work, I just want you to do it in Fedora Extras.
The first step to this is sane (and simple) standards and practices for packaging.
Or put it this way: Tell me why you're not packaging in Fedora Extras today. If its sponsorship concerns, I'll sponsor any 3rd party repository maintainer right now. Just ask me. If its packaging standards and guidelines, tell me where you're unhappy. If its personal issues, lingering burn marks from flame wars in the past, try to get over them. We're all doing this for the same reason: to provide good quality addon packages for Fedora.
I didn't really mean to give a sermon like that, but it feels better to have it out. :)
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Fri, Feb 25, 2005 at 12:01:34PM -0600, Tom 'spot' Callaway wrote:
On Fri, 2005-02-25 at 10:31 -0500, Chuck R. Anderson wrote:
On Thu, Feb 24, 2005 at 05:28:38PM -0600, Tom 'spot' Callaway wrote:
rpm -q --qf "%{version}\n" `rpm -qf /etc/redhat-release`
Instead of hard-coding the filename, how about using the Provides: that is in the package?
rpm -q --whatprovides --qf "%{version}\n" redhat-release
We can't use "--qf "%{version}\n" in the macro.
Problems with %{version} aside, my point was that Jeff Johnson mentioned to me once that the best way to get the distro version package is to get what Provides: redhat-release, not hardcoding either /etc/redhat-release or the package name redhat-release. So:
rpm -q --whatprovides redhat-release
rather than:
rpm -qf /etc/redhat-release
On Fri, 2005-02-25 at 17:48 -0500, Chuck R. Anderson wrote:
Problems with %{version} aside, my point was that Jeff Johnson mentioned to me once that the best way to get the distro version package is to get what Provides: redhat-release, not hardcoding either /etc/redhat-release or the package name redhat-release. So:
rpm -q --whatprovides redhat-release
rather than:
rpm -qf /etc/redhat-release
Ehhh... I think this may be nit-picking, but its probably right.
Alright. How about THESE macros:
# Disttag macros (you really only want to use %{disttag}) # When we get to Fedora Core 6, we'll need to revisit this.
%disttaglong %{expand:%%(rpm -q --whatprovides redhat-release --qf '%{VERSION}')} %rheldisttag %{expand:%%(echo %{disttaglong} | sed -e 's/[^0-9.]//g' -e 's/^/el/')} %rhldisttag %{expand:%%(echo %{disttaglong} | cut -d "." -f 1 | sed -e 's/^/rh/')} %fcdisttag %{expand:%%(echo %{disttaglong} | sed -e 's/^/fc/')} %disttag %{expand:%%(if echo %{disttaglong} | grep "[^0-9.]"
/dev/null; then \
case "%{rheldisttag}" in \ ( "el2" ) \ echo 0.%{rheldisttag} \ ;; \ ( "el3" ) \ echo 1.%{rheldisttag} \ ;; \ ( "el4" ) \ echo 2.%{rheldisttag} \ ;; \ ( "el5" ) \ echo 3.%{rheldisttag} \ ;; \ esac; \ else \ case "%{disttaglong}" in \ ( "7.0" | "7.1" | "7.2" | "7.3" | "8" | "9" ) \ echo 0.%{rhldisttag} \ ;; \ ( "1" | "2" | "3" ) \ echo 1.%{fcdisttag} \ ;; \ ("4" | "5" | "6" ) \ echo 2.%{fcdisttag} \ ;; \ esac; \ fi;)}
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Thu, 24 Feb 2005 17:28:38 -0600, Tom 'spot' Callaway wrote:
Maintainers would not be required to use %{disttag}. However, should they choose to do so, it should be placed at the end of the release field, preceeded by a period, e.g. Release: 1.%{disttag}.
Not with a period, of course, because if undefined, the release would included the period and become "1." instead of "1".
On Sat, 2005-02-26 at 18:29 +0100, Michael Schwendt wrote:
On Thu, 24 Feb 2005 17:28:38 -0600, Tom 'spot' Callaway wrote:
Maintainers would not be required to use %{disttag}. However, should they choose to do so, it should be placed at the end of the release field, preceeded by a period, e.g. Release: 1.%{disttag}.
Not with a period, of course, because if undefined, the release would included the period and become "1." instead of "1".
Yes, that mistake has been caught.
The syntax would be:
Release: 1%{?disttag:.%{disttag}}
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Wed, 2005-02-23 at 14:18 -0600, Tom 'spot' Callaway wrote:
Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers.
http://fedoraproject.org/wiki/PackageNamingGuidelines
Feedback is welcome, and encouraged.
It's straightforward and doesn't suffer from being painfully long-winded.
good job.
-sv
Tom 'spot' Callaway wrote :
Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers.
http://fedoraproject.org/wiki/PackageNamingGuidelines
Feedback is welcome, and encouraged.
One thing : In the "Renaming a package" section, you put :
Provides: foo Obsoletes: foo
I'd prefer having those versionned to the version of the last known package released with that name, in case the package should be renamed back some day. Typically :
You have foo = 1.0-1 that you want to rename to libfoo, then :
Provides: foo = %{version}-%{release} Obsoletes: foo <= 1.0-1
Now, say the upstream project changes the name to "foo" for their 1.1 release... having those versions in will save a lot of trouble for upgrades and updates when changing back to the new upstream name.
Thoughts?
Matthias
On Thu, 2005-02-24 at 11:26 +0100, Matthias Saou wrote:
I'd prefer having those versionned to the version of the last known package released with that name, in case the package should be renamed back some day.
Agreed. I've added that.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Wed, 2005-02-23 at 14:18 -0600, Tom 'spot' Callaway wrote:
http://fedoraproject.org/wiki/PackageNamingGuidelines
Feedback is welcome, and encouraged.
One point I did not already see mentioned: it's a good idea to check also what the rest of the world uses for a package's %{name}. If there's a common trend to call it something, and it does not conflict with the rest of our guidelines, it'd be a good idea to follow that.
Some places where this can be easily checked: http://rpm.pbone.net/ http://www.rpmseek.com/ http://rpmfind.net/
Somewhat related example case: https://bugzilla.redhat.com/149532
Tom 'spot' Callaway (tcallawa@redhat.com) said:
Working as fast as I can... here is the first draft of the Naming Policy for Fedora Extras. Its not 100% complete yet, there are at least two sections missing, but it covers the bases for most new packagers.
http://fedoraproject.org/wiki/PackageNamingGuidelines
Feedback is welcome, and encouraged.
Reading the current document:
Package Version ... If the version is non-numeric (contains tags that are not letters) ...
That doesn't sound right.
Moreover, I disagree - upstream versioning should be followed wherever possible. I suppose it depends on the package, though. To pull some recent examples:
squid - goes in Version cman - goes in Release
Perhaps a quick metric is that if the upstream is:
1.0-preX
it goes in Release, while
1.0.x
goes in Version.
Another way to potentially look at it is that alpha/beta may go in Release, but *post* release letter affixes go in Version; for example, I wouldn't want to move OpenSSL to using the letters in the release.
Bill
On Thu, 2005-02-24 at 14:01 -0500, Bill Nottingham wrote:
Another way to potentially look at it is that alpha/beta may go in Release, but *post* release letter affixes go in Version; for example, I wouldn't want to move OpenSSL to using the letters in the release.
I could see that.
So, basically:
alpha/beta/pre/cvs builds that considered "pre" releases use the Release field to note the value as documented currently.
"Final" release versions with characters can stay in the Version field.
Thoughts?
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Thu, 24 Feb 2005, Tom 'spot' Callaway wrote:
On Thu, 2005-02-24 at 14:01 -0500, Bill Nottingham wrote:
Another way to potentially look at it is that alpha/beta may go in Release, but *post* release letter affixes go in Version; for example, I wouldn't want to move OpenSSL to using the letters in the release.
I could see that.
So, basically:
alpha/beta/pre/cvs builds that considered "pre" releases use the Release field to note the value as documented currently.
"Final" release versions with characters can stay in the Version field.
Thoughts?
This is definitely the right direction. Handling alpha/beta releases isn't as high a priority as dealing with the typical release naming schemes.
-- Elliot
Tom 'spot' Callaway wrote :
On Thu, 2005-02-24 at 14:01 -0500, Bill Nottingham wrote:
Another way to potentially look at it is that alpha/beta may go in Release, but *post* release letter affixes go in Version; for example, I wouldn't want to move OpenSSL to using the letters in the release.
I could see that.
So, basically:
alpha/beta/pre/cvs builds that considered "pre" releases use the Release field to note the value as documented currently.
"Final" release versions with characters can stay in the Version field.
Thoughts?
This comes back to what Panu and I commented, and the gkrellm example given in the guidelines. If the upstream version is non-numeric but has always been "sane" to rpm version comparison, like it is the case for squid, openssl or gkrellm, then I'm all for leaving it in the version, where it rightfully belongs.
So if "Final" versions stay untouched and the release mangling only applies to pre-releases, that's fine with me.
Matthias
packaging@lists.fedoraproject.org
-
Axel Thimm -
Bill Nottingham -
Carwyn Edwards -
Chuck Anderson -
Dag Wieers -
Elliot Lee -
Enrico Scholz -
Matthias Saou -
Michael Schwendt -
Nicolas Mailhot -
Panu Matilainen -
seth vidal -
Tom Callaway -
Ville Skyttä