3:04 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Not sure if this is the right place to discuss the behaviour of RPM, but
I'm sure somebody can correct me!
I have a requirement to determine the spec file from a SRPM so that my
rpmbuild can be guaranteed to be passed a valid file.
I'd hoped to just find in the BASENAMES, however, it seems to be
filtered out when using rpm -q.
So then I thought I'd just use the RPM2 perl module. This indeed works,
excepting that it fails constantly due to bad signatures etc in packages:
error reading package at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/RPM2.pm line 85.
To my mind (i) rpm -q --qf"%{BASENAMES}" should not filter the .spec
file; and (ii) the RPM2 perl module should return as much of the header
as it can construct, with undefs etc in bad fields. Even throwing an
exception or returning an error code would at least put the decision in
user space.
I am happy to provide a patch for either if someone would indicate a
preference.
Cheers, Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBYv5DCfroLk4EZpkRAnyxAKDOUdnARVP5u+lpVI3uF7L98H2iiACfaeP3
WjZHpzRxqlW8pLxS0MtqQW8=
=5ltK
-----END PGP SIGNATURE-----
3:48 p.m.
On Wed, 06 Oct 2004 06:04:19 +1000, Alan Milligan wrote:
Not sure if this is the right place to discuss the behaviour of RPM,
but
I'm sure somebody can correct me!
I have a requirement to determine the spec file from a SRPM so that my
rpmbuild can be guaranteed to be passed a valid file.
I'd hoped to just find in the BASENAMES, however, it seems to be
filtered out when using rpm -q.
rpm -qpl package.src.rpm | grep \.spec
Or maybe I don't understand your problem. ;)
--
Fedora Core release 2 (Tettnang) - Linux 2.6.8-1.521
loadavg: 1.02 1.08 1.03
1:10 p.m.
On Tue, Oct 05, 2004 at 10:48:54PM +0200, Michael Schwendt wrote:
rpm -qpl package.src.rpm | grep \.spec
What do you do if there's more than one spec file?
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
1:19 p.m.
On Wed, Oct 06, 2004 at 02:10:30PM -0400, Matthew Miller wrote:
On Tue, Oct 05, 2004 at 10:48:54PM +0200, Michael Schwendt wrote:
> rpm -qpl package.src.rpm | grep \.spec
What do you do if there's more than one spec file?
What does rpm do when it encounters more than one .spec file in
a src.rpm when doing a "rpm --rebuild"?
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
1:47 p.m.
On Wed, 6 Oct 2004 14:10:30 -0400, Matthew Miller wrote:
> rpm -qpl package.src.rpm | grep \.spec
What do you do if there's more than one spec file?
Okay, okay. So, multiple additional spec files as %{SOURCEX} values?
Then I would use something like this
$ rpm -qp package.src.rpm --qf '[%{basenames}\n]' \
grep -v "$(rpm -qp package.src.rpm --qf '[%{source}\n]')"
or process the output with some scripting language (if need be).
--
Fedora Core release 2 (Tettnang) - Linux 2.6.8-1.521
loadavg: 1.69 1.20 1.08
1:54 p.m.
On Wed, 6 Oct 2004 20:47:02 +0200, Michael Schwendt wrote:
On Wed, 6 Oct 2004 14:10:30 -0400, Matthew Miller wrote:
> > rpm -qpl package.src.rpm | grep \.spec
>
> What do you do if there's more than one spec file?
Okay, okay. So, multiple additional spec files as %{SOURCEX} values?
Then I would use something like this
$ rpm -qp package.src.rpm --qf '[%{basenames}\n]' \
grep -v "$(rpm -qp package.src.rpm --qf '[%{source}\n]')"
or process the output with some scripting language (if need be).
| pipe missing in front of grep, although it will fail with larger
src.rpms. But apparently, original poster just was searching for the
[%{array}] notation of RPM query flags. So, comparing '[%{basenames} ]'
and '[%{source} ]' arrays would reveal the spec file name. In case
an included patch is called foo.spec, you would need to search through
'[%{patch} ]', too.
--
Fedora Core release 2 (Tettnang) - Linux 2.6.8-1.521
loadavg: 1.25 1.17 1.11
3 p.m.
What do you do if there's more than one spec file?
What srpm has more than one? I've never seen one that has more than 1 spec file
until the source tarball is opened. Sometimes there's more there for various
distro's. But I've never seen one that has more than one spec file after only
doing the rpm -i.
-Steve Grubb
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
11:30 a.m.
On Wed, 2004-10-06 at 23:00, Steve G wrote:
>What do you do if there's more than one spec file?
What srpm has more than one?
Can't tell offhand, but for example there at least used to be a
guideline in www.fedora.us somewhere stating that if providing an update
over a Fedora Core package, the original unmodified upstream (FC)
specfile should be included as a source in the SRPM. Can't find that
now, though.
11:45 a.m.
Can't tell offhand, but for example there at least used to be a
guideline in www.fedora.us somewhere stating that if providing an update
over a Fedora Core package, the original unmodified upstream (FC)
specfile should be included as a source in the SRPM.
I think its a bad idea to have a spec file contained as a SOURCE. It would make
it confusing to decide which one to use after doing a rpm -i. You would
immediately be faced with doing an rpmbuild -bb something.
I use a find command after opening the srpm to locate the spec file. It has never
failed to feed the correct spec file to my build system. (I'll be releasing the
build system sometime in the next couple days...just finishing to Text GUI for it
now.)
Spec files from upstream are almost always in the tarball so that you can do
something like rpmbuild -tb xinetd-2.3.13.tar.gz. The find command won't see
these spec files since they aren't visible until after the rpmbuild command.
-Steve Grubb
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
11:56 a.m.
On Thu, 2004-10-07 at 19:45, Steve G wrote:
I think its a bad idea to have a spec file contained as a SOURCE.
I'm not a big fan of that idea either, but:
It would make
it confusing to decide which one to use after doing a rpm -i.
"rpm -i" on a source rpm will place the real specfile in %_specdir
(/some/where/SPECS), and all sources in %_sourcedir
(/some/where/SOURCES).
12:15 p.m.
"rpm -i" on a source rpm will place the real specfile in
%_specdir
(/some/where/SPECS), and all sources in %_sourcedir
(/some/where/SOURCES).
Not really. This is configurable. Create a .rpmmacros file in the build acct's
home directory. Add these:
%_sourcedir %{_topdir}/%{name}
%_specdir %{_sourcedir}
This way all source and spec files wind up in a sane place after rpm -i. This
makes the find command work much better. ;)
-Steve Grubb
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
12:17 p.m.
On Thu, 2004-10-07 at 20:15, Steve G wrote:
>"rpm -i" on a source rpm will place the real specfile
in %_specdir
>(/some/where/SPECS), and all sources in %_sourcedir
>(/some/where/SOURCES).
Not really. This is configurable.
Yes, that's why I referred to the macros (but obviously forgot "by
default eg." in the examples).
12:36 p.m.
On Thu, 07 Oct 2004 19:30:47 +0300, Ville Skyttä wrote:
On Wed, 2004-10-06 at 23:00, Steve G wrote:
> >What do you do if there's more than one spec file?
>
> What srpm has more than one?
Can't tell offhand, but for example there at least used to be a
guideline in www.fedora.us somewhere stating that if providing an update
over a Fedora Core package, the original unmodified upstream (FC)
specfile should be included as a source in the SRPM. Can't find that
now, though.
And in case it still exists, I hope it suggests renaming the old
spec file *.spec.old or something like that.
But activity in the "patches" repository [1] has stopped a long time
ago, and we don't have any place for Fedora Alternatives yet.
[1] http://download.fedora.us/patches/
--
Fedora Core release 2.91 (FC3 Test 2) - Linux 2.6.8-1.541
loadavg: 1.17 1.17 1.30
7156
days inactive
7158
days old
12 comments
6 participants
participants (6)
-
Alan Milligan -
Jos Vos -
Matthew Miller -
Michael Schwendt -
Steve G -
Ville Skyttä