5:26 a.m.
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
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Raw Hide 20030718 running Linux kernel 2.4.20-20.1.2013.nptl
Load : 0.24 0.27 0.26
6:39 a.m.
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.
5) "The package may obsolete itself"... I really don't
get that one!
Older version, maybe?
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?
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 <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
6:56 a.m.
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
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Raw Hide 20030718 running Linux kernel 2.4.20-20.1.2013.nptl
Load : 0.17 0.20 0.22
7:16 a.m.
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 ;-).
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
6:51 a.m.
Quoting Matthias Saou <matthias(a)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... ;-)
5) "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 -
7:10 a.m.
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
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Raw Hide 20030718 running Linux kernel 2.4.20-20.1.2013.nptl
Load : 0.13 0.15 0.14
8:54 a.m.
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... ;-)
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
--
Dams Nadé
Anvil/Anvilou on irc.freenode.net : #Linux-Fr, #Fedora
I am looking for a job : http://livna.org/~anvil/cv.php
"Dona Nobis Pacem E Dona Eis Requiem". Noir.
11:35 p.m.
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/spect...
Consider something like the layout near the top of Fedora's spec
template.
Now about the guidelines... ;-)
5) "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? =)
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.
Responding to this in a new thread. Preparing flame retardant suit.
Warren Togami
warren(a)togami.com
9 a.m.
On Wed, Jul 23, 2003 at 06:35:00PM -1000, Warren Togami wrote:
>
> 5) "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.
> 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.
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(a)redhat.com (jbj(a)jbj.org)
Chapel Hill, NC
12:41 p.m.
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
2:04 p.m.
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
--
Jeff Johnson ARS N3NPQ
jbj(a)redhat.com (jbj(a)jbj.org)
Chapel Hill, NC
3:36 p.m.
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
11:43 a.m.
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?
--
\/
1:41 p.m.
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
--
Jeff Johnson ARS N3NPQ
jbj(a)redhat.com (jbj(a)jbj.org)
Chapel Hill, NC
3:21 p.m.
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.
--
\/
3:42 p.m.
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
3:55 p.m.
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
^
--
\/
6:34 a.m.
-----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
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/J61d0iMVcrivHFQRAuQXAJsHfa9yDF+n4XbTz100qEkYpqQUfwCfWiBB
I8TZFN3i3szR676+vFvpiNY=
=aZaP
-----END PGP SIGNATURE-----
3:51 p.m.
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
--
Jeff Johnson ARS N3NPQ
jbj(a)redhat.com (jbj(a)jbj.org)
Chapel Hill, NC
6:28 a.m.
-----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}
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/J6vC0iMVcrivHFQRApxfAJ9WDAC3BUWCDjXA0NP69vgmWYT/5gCghLid
txtlbVRWiBoyva7iZ9yUPQw=
=ymLt
-----END PGP SIGNATURE-----
6:47 a.m.
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.
--
\/
7574
days inactive
7582
days old
20 comments
10 participants
participants (10)
-
Dams -
Jeff Johnson -
Jos Vos -
M A Young -
Matthias Saou -
Michael Schwendt -
Panu Matilainen -
Thomas Dodd -
Ville Skyttä -
Warren Togami