Hi,
I've got a few minor remarks regarding the example spec file given here: http://rhl.redhat.com/participate/developers-guide/ch-rpm-building.html
- Summary: "The foo package does foo": Having redundancy ("the package foo") in the summary is useless IMHO, and shouldn't be encouraged. - Summary: I'd like to see an official suggestion as to whether a trailing dot should be added or omitted. If would be prettier when all go by at install time :-) - Requires vs. PreReq: AFAIK, both are now handled identically and using PreReq shouldn't be needed anymore. Jeff can correct me if I'm wrong. For explicit requirements of the %pre/%post scriplets, should the "Requires(pre):" way be suggested from now on or not? - BuildPreReq vs. BuildRequires: Same thing, and it seems even more useless to have any kind of distinction for source packages. - %description and %prep shouldn't be stuck together for readability and section separation. - %makeinstall should probably not be separated from the rest of the %install section as it's just a macro, not a separate section. - The $1, 0 and 1 from the scriplets should either be all or none quoted to keep consistent. AFAIK, $1 is always present and is an integer, so quoting is not required. - The %defattr could show the default directory mode too, by using %defattr(-, root, root, 0755) instead (or replace 0755 with - maybe) as directories might get mode 775 depending on the user's umask. - The n-e-v-r should maybe be added at the end of the first line of each %changelog entry. I don't do it myself (email address too long ;-)), but I've noticed it has become common practise inside Red Hat.
It's a nice introduction page to what a spec file is, the descriptions below are short and clear. Good work!
Now about the guidelines... ;-)
5) "The package may obsolete itself"... I really don't get that one! 6) "If a file from the package conflicts with a file from another package in the Red Hat Linux project, the package must use Conflicts: to specify it in the spec file." Should this be "Conflicts:" with the file or the package name? 12) s/specified/specify/ typo. 13) "If a newer RPM does not have a binary package that the older SRPMS produced, the binary package not produced anymore must be specified with the Obsoletes: option in the new spec file." I would also add something about encouraging to always use versions with "Obsoletes:" in order to avoid many kind of future issues when re-introducing packages for example.
Also, there is no mention of "Epoch:" usage, not even a quick note to suggest not introducing any apart from when it's really the last resort. I guess people may want to stay out of the endless discussion for as long as possible ;-) IIRC, I think I read someone mentioning somewhere that a list of current packages with full "n-e-v-r" would be maintained. With the current implementation of epoch handling in rpm >= 4.2.1, this will become a necessity when depending on specific versions of certain packages.
Long mail, hopefully not just useless talk, or else, well... "sorry" ;-) Matthias
Hi,
- Summary: I'd like to see an official suggestion as to whether a trailing dot should be added or omitted. If would be prettier when all go by at install time :-)
Agreed. I propose: summary without a trailing dot, description contains one or more complete sentences (or even paragraphs), thus with dots.
- Requires vs. PreReq: AFAIK, both are now handled identically and using PreReq shouldn't be needed anymore. Jeff can correct me if I'm wrong. For explicit requirements of the %pre/%post scriplets, should the "Requires(pre):" way be suggested from now on or not?
I didn't know it was handled the same, as the semantics are different. But I can't find the Ultimate Reference Guide for RPM right now ;-) ;-), so I don't know yet.
- The $1, 0 and 1 from the scriplets should either be all or none quoted to keep consistent. AFAIK, $1 is always present and is an integer, so quoting is not required.
True, and there is more: "=" *and* "-ge" are used, the first is an operator for string comparison, the second is an operator for number comparison. I assume it's always a number, you should use "-eq" i.s.o. "=".
- The %defattr could show the default directory mode too, by using %defattr(-, root, root, 0755) instead (or replace 0755 with - maybe) as directories might get mode 775 depending on the user's umask.
Umask is set by rpm, but I might be wrong.
- "The package may obsolete itself"... I really don't get that one!
Older version, maybe?
- "If a file from the package conflicts with a file from another package in the Red Hat Linux project, the package must use Conflicts: to specify it in the spec file." Should this be "Conflicts:" with the file or the package name?
Package name, I guess, as it would otherwise conflict with itself.
For the rest I agree with most comments. It's nice to see that others also think in so much detail about spec files, including a discussion about a dot at the end of the summary line ;-).
Jos Vos wrote :
For the rest I agree with most comments. It's nice to see that others also think in so much detail about spec files, including a discussion about a dot at the end of the summary line ;-).
But I can imagine from here poor Jeff ripping his hair off because of people discussing futile spec file aspects when there isn't even a spec file grammar :-)
I'm personally glad too to see that some initial recommendations have been written, instead of some strict guidelines that could have been tossed at everyone.
Now what I'd love to see is a publicly accessible CVS repository of all current Red Hat Linux spec files (and associated files like initscripts, patches, menu entries...). It would become much easier to track ongoing changes and submit patches. And after, even easier for Red Hat to get external contributions in one place. I guess the CVS instructions in the Developer Guide aren't there by pure luck ;-)
Matthias
Now what I'd love to see is a publicly accessible CVS repository of all current Red Hat Linux spec files (and associated files like initscripts,
I always start with
for f in somepath/*.src.rpm; do rpm2cpio $f | cpio -iuvdm '*.spec'; done
to look for all the new features in rpm ;-).
Quoting Matthias Saou matthias@rpmforge.net:
Hi,
I've got a few minor remarks regarding the example spec file given here: http://rhl.redhat.com/participate/developers-guide/ch-rpm-building.html
- Summary: "The foo package does foo": Having redundancy ("the package foo") in the summary is useless IMHO, and shouldn't be encouraged.
Seconded.
- Requires vs. PreReq: AFAIK, both are now handled identically and using PreReq shouldn't be needed anymore. Jeff can correct me if I'm wrong.
IIRC PreReq vs Requires handling only differs in presence of dependency loops. Speaking of which... would be good to point out in the docs never to create them.
For explicit requirements of the %pre/%post scriplets, should the "Requires(pre):" way be suggested from now on or not?
See http://www.fedora.us/pipermail/fedora-devel/2003-June/001457.html - how you interprete that is another deal :)
- BuildPreReq vs. BuildRequires: Same thing, and it seems even more useless to have any kind of distinction for source packages.
Yup, these are just aliases for each other.
- The n-e-v-r should maybe be added at the end of the first line of each %changelog entry. I don't do it myself (email address too long ;-)), but I've noticed it has become common practise inside Red Hat.
Some additional stuff: - "make" in %build section should probably be "make %{?_smp_mflags}" to enable paraller compiling where applicable, or at least mention that in the hints section.
It's a nice introduction page to what a spec file is, the descriptions below are short and clear. Good work!
Indeed!
Now about the guidelines... ;-)
- "The package may obsolete itself"... I really don't get that one!
Me neither, unless it means packages which have "Obsoletes: foo" and "Provides: foo" but even in that case it could be worded more clearly.
Also, there is no mention of "Epoch:" usage, not even a quick note to suggest not introducing any apart from when it's really the last resort. I guess people may want to stay out of the endless discussion for as long as possible ;-) IIRC, I think I read someone mentioning somewhere that a list of current packages with full "n-e-v-r" would be maintained. With the current implementation of epoch handling in rpm >= 4.2.1, this will become a necessity when depending on specific versions of certain packages.
Also I didn't notice any version handling guidelines. The Fedora project spent like 6 months creating a specification how to handle odd package versioning so that rpm can deal with them cleanly and there are *still* some unresolved bits. Much of the document is Fedora-specific but similar document about handling alphabets in version numbers etc would be good addition to the docs: http://www.fedora.us/wiki/PackageNamingGuidelines
Panu Matilainen wrote :
Also I didn't notice any version handling guidelines. The Fedora project spent like 6 months creating a specification how to handle odd package versioning so that rpm can deal with them cleanly and there are *still* some unresolved bits. Much of the document is Fedora-specific but similar document about handling alphabets in version numbers etc would be good addition to the docs: http://www.fedora.us/wiki/PackageNamingGuidelines
The lack of "odd package versioning" is probably because that's yet another topic many people don't want to touch even with a 20m pole, just like introducing and handling epoch ;-)
From what I can tell, RH doesn't seem so reluctant(?) to add epochs when
needed, unlike Fedora or me, as indeed they are the authoritative primary source for packages, and breaking 3rd party compatibility isn't the same as a 3rd party breaking compatibility with the main distro. I personally wouldn't mind being headed in a direction where all included packages have versions that match the upstream ones, even if this means a possible epoch introduction later on, as long as there is an exhaustive list of all RHL packages with their complete current n-e-v-r. Maybe there are drawbacks that I'm missing though, in which case I'd really like to know.
Matthias
I see in the template there is %{buildroot}. I thought JBJ told once $RPM_BUILD_ROOT was the 'official way' and %{buildroot} might be changed/removed one day.. According to this, fedora, who firstly used %{buildroot}, modified [almost] all spec files to use $RPM_BUILD_ROOT instead... So ? Who is 'wrong' ? What to do ?
D
Le mar 22/07/2003 à 12:26, Matthias Saou a écrit :
Hi,
I've got a few minor remarks regarding the example spec file given here: http://rhl.redhat.com/participate/developers-guide/ch-rpm-building.html
- Summary: "The foo package does foo": Having redundancy ("the package foo") in the summary is useless IMHO, and shouldn't be encouraged.
- Summary: I'd like to see an official suggestion as to whether a trailing dot should be added or omitted. If would be prettier when all go by at install time :-)
- Requires vs. PreReq: AFAIK, both are now handled identically and using PreReq shouldn't be needed anymore. Jeff can correct me if I'm wrong. For explicit requirements of the %pre/%post scriplets, should the "Requires(pre):" way be suggested from now on or not?
- BuildPreReq vs. BuildRequires: Same thing, and it seems even more useless to have any kind of distinction for source packages.
- %description and %prep shouldn't be stuck together for readability and section separation.
- %makeinstall should probably not be separated from the rest of the %install section as it's just a macro, not a separate section.
- The $1, 0 and 1 from the scriplets should either be all or none quoted to keep consistent. AFAIK, $1 is always present and is an integer, so quoting is not required.
- The %defattr could show the default directory mode too, by using %defattr(-, root, root, 0755) instead (or replace 0755 with - maybe) as directories might get mode 775 depending on the user's umask.
- The n-e-v-r should maybe be added at the end of the first line of each %changelog entry. I don't do it myself (email address too long ;-)), but I've noticed it has become common practise inside Red Hat.
It's a nice introduction page to what a spec file is, the descriptions below are short and clear. Good work!
Now about the guidelines... ;-)
- "The package may obsolete itself"... I really don't get that one!
- "If a file from the package conflicts with a file from another package in the Red Hat Linux project, the package must use Conflicts: to specify it in the spec file." Should this be "Conflicts:" with the file or the package name?
- s/specified/specify/ typo.
- "If a newer RPM does not have a binary package that the older SRPMS produced, the binary package not produced anymore must be specified with the Obsoletes: option in the new spec file." I would also add something about encouraging to always use versions with "Obsoletes:" in order to avoid many kind of future issues when re-introducing packages for example.
Also, there is no mention of "Epoch:" usage, not even a quick note to suggest not introducing any apart from when it's really the last resort. I guess people may want to stay out of the endless discussion for as long as possible ;-) IIRC, I think I read someone mentioning somewhere that a list of current packages with full "n-e-v-r" would be maintained. With the current implementation of epoch handling in rpm >= 4.2.1, this will become a necessity when depending on specific versions of certain packages.
Long mail, hopefully not just useless talk, or else, well... "sorry" ;-) Matthias
On Tue, 2003-07-22 at 00:26, Matthias Saou wrote:
- Summary: I'd like to see an official suggestion as to whether a
trailing dot should be added or omitted. If would be prettier when all go by at install time :-)
What do you mean?
- %description and %prep shouldn't be stuck together for readability
and section separation.
+1 http://cvs.fedora.us/cgi-bin/cvsweb.cgi/packages/fedora-rpmdevtools/spectemp... Consider something like the layout near the top of Fedora's spec template.
Now about the guidelines... ;-)
- "The package may obsolete itself"... I really don't get that one!
When we hear the answer to this, can we have links from the RHLP page to more detailed information describing "why" and examples where it is used?
Can we Wiki this? =)
- "If a newer RPM does not have a binary package that the older
SRPMS produced, the binary package not produced anymore must be specified with the Obsoletes: option in the new spec file." I would also add something about encouraging to always use versions with "Obsoletes:" in order to avoid many kind of future issues when re-introducing packages for example.
Also, there is no mention of "Epoch:" usage, not even a quick note to suggest not introducing any apart from when it's really the last resort. I guess people may want to stay out of the endless discussion for as long as possible ;-) IIRC, I think I read someone mentioning somewhere that a list of current packages with full "n-e-v-r" would be maintained. With the current implementation of epoch handling in rpm >= 4.2.1, this will become a necessity when depending on specific versions of certain packages.
Responding to this in a new thread. Preparing flame retardant suit.
Warren Togami warren@togami.com
On Wed, Jul 23, 2003 at 06:35:00PM -1000, Warren Togami wrote:
- "The package may obsolete itself"... I really don't get that one!
When we hear the answer to this, can we have links from the RHLP page to more detailed information describing "why" and examples where it is used?
Can we Wiki this? =)
Every package obsoletes (i.e. erases) itself when using --upgrade.
Obsoletes: is commonly used to get rid of a differently named but otherwise nearly identical package. In order to resolve dependencies, the new package often carries a Provides:. So what a packager sees is Name: newfoo ... Obsoletes: oldfoo Provides: oldfoo leading to a confusion based on (from user POV) newfoo == oldfoo interpretation.
The only other case I can think of where a packager might consider adding Name: foo ... Obsoletes: foo is to attempt to get rid of other copies of packages if rpm is invoked with --install. Not gonna work, doesn't afaik, as the promise of --install is No information will ever be erased if invoked with --install. There's enough conflicting features and policies in rpm that it wouldn't surprise me to hear about some exotic corner case, but that's a bug imho.
- "If a newer RPM does not have a binary package that the older
SRPMS produced, the binary package not produced anymore must be specified with the Obsoletes: option in the new spec file." I would also add something about encouraging to always use versions with "Obsoletes:" in order to avoid many kind of future issues when re-introducing packages for example.
Also, there is no mention of "Epoch:" usage, not even a quick note to suggest not introducing any apart from when it's really the last resort. I guess people may want to stay out of the endless discussion for as long as possible ;-) IIRC, I think I read someone mentioning somewhere that a list of current packages with full "n-e-v-r" would be maintained. With the current implementation of epoch handling in rpm >= 4.2.1, this will become a necessity when depending on specific versions of certain packages.
Responding to this in a new thread. Preparing flame retardant suit.
Current behavior in rpm-4.2.1 (and all future versions of rpm) is A missing (i.e. unsepcified) Epoch: is exactly equivalent to Epoch: 0.
Whether you choose to make the Epoch: explicit is a matter of style, the version comparison in rpm is now deterministic, the same answer is returned every time.
I'd suggest that broken packages (i.e. missing Epoch: is needed) are more easily handled with rpm -Va --nofiles --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ i.e. verify that the dependencies of each package are satisfied within the universe of packages contained in, say, the rpmdb-redhat package for the distro, becuase a) missing Epoch: is just a special case of a more general problem, dependency closure for a collection of packages called a distro. a) closure on dependencies cannot be easily detected by a packager, but is trivial (and necessary) to check by a distro release manager.
(aside) I'd like to add the closure check to rpmbuild, what stops me is that noone is willing to figger means to maintain the equivalent of a rpmdb-redhat package incrementally. Without that, it's premature to check for dependency closure in rpmbuild. So the immediate problem is to establish the need of creating a rpmdb-redhat database so that the tools necessary to do the job can start being written.
73 de Jeff
-- Jeff Johnson ARS N3NPQ jbj@redhat.com (jbj@jbj.org) Chapel Hill, NC
On Thu, 24 Jul 2003, Jeff Johnson wrote:
(aside) I'd like to add the closure check to rpmbuild, what stops me is that noone is willing to figger means to maintain the equivalent of a rpmdb-redhat package incrementally. Without that, it's premature to check for dependency closure in rpmbuild. So the immediate problem is to establish the need of creating a rpmdb-redhat database so that the tools necessary to do the job can start being written.
What are the problems with doing this with the justdb flag? It seems to me that you could do this automatically, based on the packages in rawhide say, though presumably it can't be that simple or it would already have been done.
Michael Young
On Thu, Jul 24, 2003 at 06:41:41PM +0100, M A Young wrote:
On Thu, 24 Jul 2003, Jeff Johnson wrote:
(aside) I'd like to add the closure check to rpmbuild, what stops me is that noone is willing to figger means to maintain the equivalent of a rpmdb-redhat package incrementally. Without that, it's premature to check for dependency closure in rpmbuild. So the immediate problem is to establish the need of creating a rpmdb-redhat database so that the tools necessary to do the job can start being written.
What are the problems with doing this with the justdb flag? It seems to me that you could do this automatically, based on the packages in rawhide say, though presumably it can't be that simple or it would already have been done.
Yup, --justdb works quite well. The issue is who is willing to maintain, not whether rpm supports. Different problems, one process, the other mechanism.
Further refinements on mechanism are quite possible, it's not like adding the line of code rc = rpmdbAdd(rpmdb_redhatdb, buildtime, h, NULL, NULL); is hard for me to implement in rpm or anything.
But that is only mechanism, what's needed is thought on the policy on when to do that, and which database to choose.
73 de Jeff
On Thu, 24 Jul 2003, Jeff Johnson wrote:
Yup, --justdb works quite well. The issue is who is willing to maintain, not whether rpm supports. Different problems, one process, the other mechanism.
I think we were thinking along different lines. I was thinking of a process which runs maybe daily on the central rpm repository, generates an rpmdb-redhat type database, and uses this to report back dependency errors to the package maintainer, which should be relatively easy to do with the existing rpm, and probably very little additional programming. It also means it would be a QA problem setting it up, rather than yours!
To achieve the same thing at build time is more difficult, because anyone building an rpm would probably need an up to date copy of the master rpmdb so they know the latest situation on any package they have dependencies, and there would probably have to be some central checking anyway, so that you can spot inconsistencies based on simultaneous updates or if package is withdrawn. Moreover if you require such a check, there might be problems if someone has to update 2 interdependent packages at the same time.
Other central checking that would be useful would be whether there are any dependency difficulties with regard to the last release, eg. are the package versions strictly increasing, and are all non-superceded packages deliberate or should they be obsoleted by another package.
Michael Young
On Thu, 2003-07-24 at 17:00, Jeff Johnson wrote:
Current behavior in rpm-4.2.1 (and all future versions of rpm) is A missing (i.e. unsepcified) Epoch: is exactly equivalent to Epoch: 0.
Whether you choose to make the Epoch: explicit is a matter of style, the version comparison in rpm is now deterministic, the same answer is returned every time.
Let's consider a specfile without an explicit Epoch that produces packages foo and foo-devel. Does this work in foo-devel with rpm-4.2.1?
Requires: foo = %{epoch}:%{version}
IIRC it doesn't work in rpm-4.2 and earlier. It'd be nice if it worked, in the case of an Epoch bump later the inter-subpackage dependencies would automagically follow if one doesn't fancy putting the explicit "Epoch: 0"'s in specfiles.
Also, outputting the 0 in cases of a missing Epoch would be nice too, I remember trying out rpm-4.2.1 on RHL 9, and trying to install glib and glib-devel (Epoch: 1, but a buggy requires in -devel; fixed in Severn). The error message IIRC was:
glib = x.x.x is required by glib-devel
...whereas a less confusing one IMHO would have been:
glib = 0:x.x.x is required by glib-devel
Ditto for "rpm -q --qf '%{epoch}:%{version}-%{release}' foo", does/could 4.2.1 print out "0:x.y-z" instead of "(none):x.y-z" if foo doesn't have an explicit Epoch?
On Sun, Jul 27, 2003 at 07:43:54PM +0300, Ville Skyttä wrote:
On Thu, 2003-07-24 at 17:00, Jeff Johnson wrote:
Current behavior in rpm-4.2.1 (and all future versions of rpm) is A missing (i.e. unsepcified) Epoch: is exactly equivalent to Epoch: 0.
Whether you choose to make the Epoch: explicit is a matter of style, the version comparison in rpm is now deterministic, the same answer is returned every time.
Let's consider a specfile without an explicit Epoch that produces packages foo and foo-devel. Does this work in foo-devel with rpm-4.2.1?
Requires: foo = %{epoch}:%{version}
IIRC it doesn't work in rpm-4.2 and earlier. It'd be nice if it worked,
You do not recall correctly. Without "doesn't work" definition no further analysis is possible.
There are 3 behaviors wrto epoch in rpm (well 4 or 5, but early one's don't really matter any more):
a) Ignore Epoch: if either value is missing. This was the behavior from rpm-3.0.2 (when versioned dependencies were implemented) until rpm-4.1. The packageing rule that was mandated at the time rpm-3.0.2 was released was If foo has explicit epoch, then foo-devel must have Requires: foo = E:V Well that worked fine, until Red Hat released a package that was not upgradeable, libogg or vorbis. This became a MUSTFIX for Red Hat 8.0 and the constraint on the problem ws "No package upgrades.". So the only solution that I could devise was
b) For added packages, use behavior a), otherwise treat missing Epoch: as Epoch: 0.
This is seriously confusing as two answers for rpm version comparison become possible.
So, to give absolutely deterministic behavior in the future, rpm-4.2.1 is going forward with c) A missing (unspecified) Epoch: is exactly equivalent to Epoch: 0.
in the case of an Epoch bump later the inter-subpackage dependencies would automagically follow if one doesn't fancy putting the explicit "Epoch: 0"'s in specfiles.
Also, outputting the 0 in cases of a missing Epoch would be nice too, I remember trying out rpm-4.2.1 on RHL 9, and trying to install glib and glib-devel (Epoch: 1, but a buggy requires in -devel; fixed in Severn). The error message IIRC was:
glib = x.x.x is required by glib-devel
...whereas a less confusing one IMHO would have been:
glib = 0:x.x.x is required by glib-devel
Ditto for "rpm -q --qf '%{epoch}:%{version}-%{release}' foo", does/could 4.2.1 print out "0:x.y-z" instead of "(none):x.y-z" if foo doesn't have an explicit Epoch?
Please apply the rule: A missing (unspecified) Epoch: is exactly equivalent to Epoch: 0.
*Please*.
73 de Jeff
On Mon, 2003-07-28 at 21:41, Jeff Johnson wrote:
On Sun, Jul 27, 2003 at 07:43:54PM +0300, Ville Skyttä wrote:
On Thu, 2003-07-24 at 17:00, Jeff Johnson wrote:
Current behavior in rpm-4.2.1 (and all future versions of rpm) is A missing (i.e. unsepcified) Epoch: is exactly equivalent to Epoch: 0.
Whether you choose to make the Epoch: explicit is a matter of style, the version comparison in rpm is now deterministic, the same answer is returned every time.
Perhaps internally, when versioned dependencies are being resolved. But *not always*. The base assumption I'm making here is that eg. rpm-4.2.1-0.11 in Severn represents the "current behavior" as in the above.
Believe me, I've followed the Epoch discussion closely enough, and have read the history why it was made the way it is in 4.2.1. IMO that's good.
And yes, I'm nitpicking, very much so. See below, and beware, this is more verbose than I would like it to be. Sorry.
Let's consider a specfile without an explicit Epoch that produces packages foo and foo-devel. Does this work in foo-devel with rpm-4.2.1?
Requires: foo = %{epoch}:%{version}
IIRC it doesn't work in rpm-4.2 and earlier. It'd be nice if it worked,
You do not recall correctly. Without "doesn't work" definition no further analysis is possible.
"Doesn't work" == "The package cannot be built". And with this definition, it turns out that I do remember correctly; it "doesn't work" with 4.2. Nor does it with 4.2.1. See the attached specfile, here are some test results with it:
rpm-4.2-1 on Shrike:
$ rpmbuild -bb foo.spec error: line 8: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: %{epoch}:1-1.0
rpm-4.2.1-0.11 on Severn:
$ rpmbuild -bb foo.spec error: line 8: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: %{epoch}:1-1.0
If "no Epoch" == "Epoch: 0" in 4.2.1, why the error? It is *not* a matter of style; if I add the explicit "Epoch: 0" in the attached foo.spec, the rpmbuild completes with both versions.
Also, outputting the 0 in cases of a missing Epoch would be nice too, I remember trying out rpm-4.2.1 on RHL 9, and trying to install glib and glib-devel (Epoch: 1, but a buggy requires in -devel; fixed in Severn). The error message IIRC was:
glib = x.x.x is required by glib-devel
...whereas a less confusing one IMHO would have been:
glib = 0:x.x.x is required by glib-devel
Ditto for "rpm -q --qf '%{epoch}:%{version}-%{release}' foo", does/could 4.2.1 print out "0:x.y-z" instead of "(none):x.y-z" if foo doesn't have an explicit Epoch?
Please apply the rule: A missing (unspecified) Epoch: is exactly equivalent to Epoch: 0.
*Please*.
I can apply that. But why? rpm has already applied the rule, why do I have to remember to apply it? Why not go all the way and make it explicit and clear everywhere by always outputting "0" instead of "(none)" (eg. in --qf %{epoch}) or leaving it out altogether as in the example above?
Just for the record, here is the exact output of the case above, on a Shrike box after upgrading to rpm-4.2.1-0.15.fdr.1:
# rpm -q --qf "%{name}-%{epoch}:%{version}-%{release}\n" glib glib-1:1.2.10-10 # rpm -Uvh glib-devel-1.2.10-10.i386.rpm error: Failed dependencies: glib = 1.2.10 is needed by glib-devel-1.2.10-10
Yes, *I know* there's a missing "1:" in this particular glib-devel-to-glib-dependency but why isn't the error message the following, IMO less confusing one?
error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-1.2.10-10
Will shut up now. Hopefully I haven't annoyed anyone.
Ville Skyttä wrote:
And yes, I'm nitpicking, very much so. See below, and beware, this is more verbose than I would like it to be. Sorry.
<snip>
Just for the record, here is the exact output of the case above, on a Shrike box after upgrading to rpm-4.2.1-0.15.fdr.1:
# rpm -q --qf "%{name}-%{epoch}:%{version}-%{release}\n" glib glib-1:1.2.10-10 # rpm -Uvh glib-devel-1.2.10-10.i386.rpm error: Failed dependencies: glib = 1.2.10 is needed by glib-devel-1.2.10-10
Yes, *I know* there's a missing "1:" in this particular glib-devel-to-glib-dependency but why isn't the error message the following, IMO less confusing one?
error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-1.2.10-10
Just to nitpick a little more, shouldn't that be:
error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-0:1.2.10-10
For completeness?
-Thomas
On Mon, 2003-07-28 at 23:42, Thomas Dodd wrote:
Just to nitpick a little more, shouldn't that be:
error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-0:1.2.10-10
For completeness?
Couldn't resist to comment :)
That would be sort of new functionality, epochs haven't traditionally appeared in foo-x.x-x -style outputs (not that I would have anything against it, +1 FWIW), whereas in foo = x:x.x-x they are and have been visible when _explicit_ epochs, for all values of them, are involved.
But in this particular case, following your suggestion, the message should actually be this :}
error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-1:1.2.10-10 ^
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 28 Jul 2003 15:42:12 -0500, Thomas Dodd wrote:
error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-1.2.10-10
Just to nitpick a little more, shouldn't that be:
error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-0:1.2.10-10
For completeness?
:)
Because glib-devel-1.2.10-10 denotes a package file name and epochs have never been part of the rpm file name.
In either place, the epoch would only cause more confusion among users:
error: Failed dependencies: glib = 1.2.10 is needed by glib-devel-1.2.10-10
Is uncomprehensible for the user when he tried to install glib-devel-1.2.10-10 and doesn't know about epochs.
error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-1.2.10-10
Is uncomprehensible for the user when he has glib-1.2.10-10 and doesn't know where to get glib-0:1.2.10-10. ;-P
- --
On Mon, Jul 28, 2003 at 11:21:20PM +0300, Ville Skyttä wrote:
rpm-4.2-1 on Shrike:
$ rpmbuild -bb foo.spec error: line 8: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: %{epoch}:1-1.0
Bah, pure syntax, packaging error. Try Requires: %{name} = %{?epoch:%{epoch}:}%{version}
If epoch exists, than prefix with epoch value and ':' etc, etc
And this syntax is supported (or broken ;-), in almost all rpm releases back to rpm-3.0.
I can apply that. But why? rpm has already applied the rule, why do I
Above is a rule that applies. If epoch is used, then add; otherwise don't bother.
have to remember to apply it? Why not go all the way and make it explicit and clear everywhere by always outputting "0" instead of "(none)" (eg. in --qf %{epoch}) or leaving it out altogether as in the example above?
Just for the record, here is the exact output of the case above, on a Shrike box after upgrading to rpm-4.2.1-0.15.fdr.1:
# rpm -q --qf "%{name}-%{epoch}:%{version}-%{release}\n" glib glib-1:1.2.10-10 # rpm -Uvh glib-devel-1.2.10-10.i386.rpm error: Failed dependencies: glib = 1.2.10 is needed by glib-devel-1.2.10-10
Yes, *I know* there's a missing "1:" in this particular glib-devel-to-glib-dependency but why isn't the error message the following, IMO less confusing one?
error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-1.2.10-10
Not annoyed, Epoch: just gets old sometimes.
73 de Jeff
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 28 Jul 2003 23:21:20 +0300, Ville Skyttä wrote:
"Doesn't work" == "The package cannot be built". And with this definition, it turns out that I do remember correctly; it "doesn't work" with 4.2. Nor does it with 4.2.1. See the attached specfile, here are some test results with it:
rpm-4.2-1 on Shrike:
$ rpmbuild -bb foo.spec error: line 8: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: %{epoch}:1-1.0
rpm-4.2.1-0.11 on Severn:
$ rpmbuild -bb foo.spec error: line 8: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: %{epoch}:1-1.0
If "no Epoch" == "Epoch: 0" in 4.2.1, why the error? It is *not* a matter of style; if I add the explicit "Epoch: 0" in the attached foo.spec, the rpmbuild completes with both versions.
Package name is missing in here:
Requires: %{epoch}:%{version}-%{release}
- --
On Wed, 2003-07-30 at 14:28, Michael Schwendt wrote:
If "no Epoch" == "Epoch: 0" in 4.2.1, why the error? It is *not* a matter of style; if I add the explicit "Epoch: 0" in the attached foo.spec, the rpmbuild completes with both versions.
Package name is missing in here:
Requires: %{epoch}:%{version}-%{release}
*blush* Note to self: no late-at-night posts.
Anyway, when the spec is fixed, it builds w/ rpm 4.2 and 4.2.1 but results in "foo = %{epoch}:1-1.0" dependency (not 0:1-1.0) to the main package in -devel with both.
Jeff's "%{name} = %{?epoch:%{epoch}:}%{version}" 'workaround' works.
-
Dams -
Jeff Johnson -
Jos Vos -
M A Young -
Matthias Saou -
Michael Schwendt -
Panu Matilainen -
Thomas Dodd -
Ville Skyttä -
Warren Togami