11:26 a.m.
The current suggestion on the Packaging/Perl wiki page is (for Requires,
Provides works the same) is:
----------------------------------------------------------------------
# Filter unwanted Requires:
cat << \EOF > %{name}-req
#!/bin/sh
%{__perl_requires} $* |\
sed -e '/perl(unwanted_require)/d'
EOF
%define __perl_requires %{_builddir}/%{name}-%{version}/%{name}-req
chmod +x %{__perl_requires}
----------------------------------------------------------------------
This won't work for the majority of perl modules because the build
directory is %{_builddir}/MODULENAME-%{version} rather than
%{_builddir}/%{name}-%{version}.
A simpler way that avoids generating script files at all might be:
%global filtered_requires sh -c '%{__perl_requires} "$@" | %{__sed} -e
"/^perl(unwanted_require)$/d"'
%define __perl_requires %{filtered_requires}
Anyone see any problems with this?
P.S. I'm not an rpm macro expert and don't really know the significance
of %global but using %define in its place results in a recursive macro
definition, which doesn't work.
Paul.
2:05 p.m.
On Wed, 2006-03-01 at 17:26 +0000, Paul Howarth wrote:
%global filtered_requires sh -c '%{__perl_requires}
"$@" | %{__sed} -e
"/^perl(unwanted_require)$/d"'
%define __perl_requires %{filtered_requires}
Anyone see any problems with this?
I don't see any technical problems offhand, but it'll sure get ugly when
one needs to filter many provides/requires because IIRC the whole
"%global ..." shebang needs to be on one line.
3:52 p.m.
On Wed, 2006-03-01 at 22:05 +0200, Ville Skyttä wrote:
On Wed, 2006-03-01 at 17:26 +0000, Paul Howarth wrote:
> %global filtered_requires sh -c '%{__perl_requires} "$@" | %{__sed} -e
> "/^perl(unwanted_require)$/d"'
> %define __perl_requires %{filtered_requires}
>
> Anyone see any problems with this?
I don't see any technical problems offhand, but it'll sure get ugly when
one needs to filter many provides/requires because IIRC the whole
"%global ..." shebang needs to be on one line.
OK, revised version:
%define bogusreqs 'perl(Bad::Module)\
perl(Some::Other::Bad::Module)\
perl(Yet::Other::Bad::Module)\
perl(And::Other::Bad::Module)\
something-else-entirely\
last-thing'
%global reqfilt sh -c "%{__perl_requires} | %{__grep} -Fv %{bogusreqs}"
%define __perl_requires %{reqfilt}
Paul.
12:55 a.m.
On Wed, 2006-03-01 at 21:52 +0000, Paul Howarth wrote:
OK, revised version:
%define bogusreqs 'perl(Bad::Module)\
perl(Some::Other::Bad::Module)\
perl(Yet::Other::Bad::Module)\
perl(And::Other::Bad::Module)\
something-else-entirely\
last-thing'
%global reqfilt sh -c "%{__perl_requires} | %{__grep} -Fv %{bogusreqs}"
%define __perl_requires %{reqfilt}
That approach fails to filter any dependencies here.
5:17 a.m.
Ville Skyttä wrote:
On Wed, 2006-03-01 at 21:52 +0000, Paul Howarth wrote:
>OK, revised version:
>
>%define bogusreqs 'perl(Bad::Module)\
>perl(Some::Other::Bad::Module)\
>perl(Yet::Other::Bad::Module)\
>perl(And::Other::Bad::Module)\
>something-else-entirely\
>last-thing'
>%global reqfilt sh -c "%{__perl_requires} | %{__grep} -Fv %{bogusreqs}"
>%define __perl_requires %{reqfilt}
That approach fails to filter any dependencies here.
Curious. I tried it on a Net-SSH-Perl package on FC4 and used:
%define bogusreqs 'perl(Crypt::RSA)\
perl(Crypt::RSA::Key)\
perl(Crypt::RSA::Key::Private)\
perl(Crypt::RSA::Key::Public)\
perl(Crypt::RSA::Primitives)\
perl(Crypt::RSA::SS::PKCS1v15)'
%global reqfilt sh -c "%{__perl_requires} | %{__grep} -Fv %{bogusreqs}"
%define __perl_requires %{reqfilt}
and it did indeed remove all of the Crypt::RSA* deps (not that I
actually wanted to do this, it was just for test purposes).
The bogusreqs macro is a list of fixed strings, one per line, and should
only need escaping if it needed to include a single quote character I think.
Paul.
10:43 a.m.
On Thu, 2006-03-02 at 11:17 +0000, Paul Howarth wrote:
Curious. I tried it on a Net-SSH-Perl package on FC4 and used:
Is that package available somewhere online?
%define bogusreqs 'perl(Crypt::RSA)\
perl(Crypt::RSA::Key)\
perl(Crypt::RSA::Key::Private)\
perl(Crypt::RSA::Key::Public)\
perl(Crypt::RSA::Primitives)\
perl(Crypt::RSA::SS::PKCS1v15)'
%global reqfilt sh -c "%{__perl_requires} | %{__grep} -Fv %{bogusreqs}"
%define __perl_requires %{reqfilt}
and it did indeed remove all of the Crypt::RSA* deps (not that I
actually wanted to do this, it was just for test purposes).
Curious indeed. I tried adding this to the top of perl-Net-SSH.spec in
Extras devel branch in CVS:
%define bogusreqs 'perl(IPC::Open2)\
perl(IPC::Open3)'
%global reqfilt sh -c "%{__perl_requires} | %{__grep} -Fv %{bogusreqs}"
%define __perl_requires %{reqfilt}
...but after rebuilding the resulting SRPM on FC-4 and Rawhide the
perl(IPC::Open*) dependencies were still there in both binary packages.
11:34 a.m.
Ville Skyttä wrote:
On Thu, 2006-03-02 at 11:17 +0000, Paul Howarth wrote:
>Curious. I tried it on a Net-SSH-Perl package on FC4 and used:
Is that package available somewhere online?
Not yet; I hope to submit one to Extras shortly.
>%define bogusreqs 'perl(Crypt::RSA)\
>perl(Crypt::RSA::Key)\
>perl(Crypt::RSA::Key::Private)\
>perl(Crypt::RSA::Key::Public)\
>perl(Crypt::RSA::Primitives)\
>perl(Crypt::RSA::SS::PKCS1v15)'
>%global reqfilt sh -c "%{__perl_requires} | %{__grep} -Fv %{bogusreqs}"
>%define __perl_requires %{reqfilt}
>
>and it did indeed remove all of the Crypt::RSA* deps (not that I
>actually wanted to do this, it was just for test purposes).
Curious indeed. I tried adding this to the top of perl-Net-SSH.spec in
Extras devel branch in CVS:
%define bogusreqs 'perl(IPC::Open2)\
perl(IPC::Open3)'
%global reqfilt sh -c "%{__perl_requires} | %{__grep} -Fv %{bogusreqs}"
%define __perl_requires %{reqfilt}
...but after rebuilding the resulting SRPM on FC-4 and Rawhide the
perl(IPC::Open*) dependencies were still there in both binary packages.
I was able to repeat this.
Moving the defines to %prep fixed it. Not sure why that worked.
Paul.
1:20 p.m.
I just want to throw this idea out for everyone to consider. I'm not
100% happy with it, but I can't say I'm 100% happy with any other
solution I've seen.
Let me state for the record that TMTOWTDI, but I'm looking for
something that I can script in cpanspec, that doesn't litter
%_sourcedir, that honors %__perl_requires, and that isn't *too* ugly.
I'm using the perl-Kwiki-Raw package (not yet submitted, but available
at http://ftp.kspei.com/pub/steve/rpms/perl-Kwiki-Raw/) as my test.
In it, I need to filter a dependency on "perl(mixin)".
First, I added the following to the spec:
Source1: filter-requires.sh
%global real_perl_requires %{__perl_requires}
%define __perl_requires %{SOURCE1}
Then, in %prep, added the following:
sed -i -e 's,@@PERL_REQ@@,%{real_perl_requires},' %{SOURCE1}
The filter_requires.sh looks like this:
#!/bin/sh
@@PERL_REQ@@ "$@" | sed -e '/^perl(mixin)$/d'
Yes, this changes filter-requires.sh, so any source rpm built from
this will have @@PERL_REQ@@ pre-substituted, but is that really a
major problem?
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
2:10 p.m.
>>>> "SP" == Steven Pritchard
<steve(a)silug.org> writes:
SP> Yes, this changes filter-requires.sh, so any source rpm built from
SP> this will have @@PERL_REQ@@ pre-substituted, but is that really a
SP> major problem?
I think any modification to the source directory is going to be
problematic. There's no guarantee that the RPM builder is going to
have write access to that directory. (It won't work one of my setups,
where that directory is readable but not writable by the user I build
RPMs as.)
So where are we at? We can't mess with buildroot (because the
module's signing stuff will complain) and we can't mess with
sourcedir. How about just making another directory:
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)-blah
emitting the script there (or copying it through sed to do the
expansion) and then cleaning it up in %clean?
- J<
2:49 p.m.
On Wed, Mar 08, 2006 at 02:10:12PM -0600, Jason L Tibbitts III wrote:
So where are we at? We can't mess with buildroot (because the
module's signing stuff will complain) and we can't mess with
sourcedir. How about just making another directory:
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)-blah
emitting the script there (or copying it through sed to do the
expansion) and then cleaning it up in %clean?
I think I like that. It's not too ugly, and it satisfies all of my
concerns.
We add this:
Source1: filter-requires.sh
%global real_perl_requires %{__perl_requires}
%define __perl_requires %%{_tmppath}/%{name}-%{version}-%{release}-%(%{__id_u}
-n)-filter-requires
Then in %prep do this:
sed -e 's,@@PERL_REQ@@,%{real_perl_requires},' %{SOURCE1} >
%{__perl_requires}
chmod +x %{__perl_requires}
And make %clean this:
rm -rf $RPM_BUILD_ROOT %{__perl_requires}
I've updated the perl-Kwiki-Raw spec to use this instead.
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
1:44 a.m.
On Wed, 2006-03-08 at 14:49 -0600, Steven Pritchard wrote:
On Wed, Mar 08, 2006 at 02:10:12PM -0600, Jason L Tibbitts III
wrote:
> So where are we at? We can't mess with buildroot (because the
> module's signing stuff will complain) and we can't mess with
> sourcedir. How about just making another directory:
>
> %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)-blah
>
> emitting the script there (or copying it through sed to do the
> expansion) and then cleaning it up in %clean?
I think I like that. It's not too ugly, and it satisfies all of my
concerns.
I don't quite understand what makes writing an external script and then
modifying it from the specfile better than just emitting the script
completely from the .spec in %prep, given that the script will usually
be just a few lines.
Source1: filter-requires.sh
For a guideline, that's a too generic filename.
%{name}-filter-requires.sh would be better.
%define __perl_requires
%%{_tmppath}/%{name}-%{version}-%{release}-%(%{__id_u} -n)-filter-requires
Could possibly use %define __perl_requires %{buildroot}-filter-requires
(untested). The double %% appears to be a typo.
9:02 a.m.
On Thu, Mar 09, 2006 at 09:44:51AM +0200, Ville Skyttä wrote:
I don't quite understand what makes writing an external script
and then
modifying it from the specfile better than just emitting the script
completely from the .spec in %prep, given that the script will usually
be just a few lines.
I'm definitely not saying it is better. It's a little bit
cleaner-looking maybe.
> Source1: filter-requires.sh
For a guideline, that's a too generic filename.
%{name}-filter-requires.sh would be better.
I changed it to that in cpanspec (just committed to CVS if you feel
like fighting sourceforge's CVS).
> %define __perl_requires
%%{_tmppath}/%{name}-%{version}-%{release}-%(%{__id_u} -n)-filter-requires
Could possibly use %define __perl_requires %{buildroot}-filter-requires
(untested). The double %% appears to be a typo.
It is.
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
11:05 a.m.
On Thu, 2006-03-09 at 09:02 -0600, Steven Pritchard wrote:
fighting sourceforge's CVS).
OT: in case you didn't know, SourceForge now offers Subversion too. I
switched one project over and have been very pleased so far. *knocks
wood* https://sourceforge.net/forum/forum.php?forum_id=544830
2:45 a.m.
On Wed, 2006-03-08 at 14:10 -0600, Jason L Tibbitts III wrote:
>>>>> "SP" == Steven Pritchard
<steve(a)silug.org> writes:
SP> Yes, this changes filter-requires.sh, so any source rpm built from
SP> this will have @@PERL_REQ@@ pre-substituted, but is that really a
SP> major problem?
I think any modification to the source directory is going to be
problematic. There's no guarantee that the RPM builder is going to
have write access to that directory. (It won't work one of my setups,
where that directory is readable but not writable by the user I build
RPMs as.)
Why not modify the script so that instead of having to substitute
@@PERL_REQ@@, the necessary value is passed as a parameter to it?
So the spec looks like this:
...
Source1: filter-requires.sh
...
%prep
%setup -q -n Kwiki-Raw-%{version}
%global real_perl_requires %{__perl_requires}
%define __perl_requires %{SOURCE1} %{real_perl_requires}
There's no need to delete anything extra in %clean
The filter-requires.sh looks like this:
#!/bin/sh
PERL_REQ="$1"; shift
"${PERL_REQ}" "$@" | /bin/grep -Fvx '
perl(mixin)
'
Where multiple dependencies need to be filtered, add them one per line
where perl(mixin) is.
The only "unusual" requirement here is that the filter-requires.sh needs
to be executable in the SRPM, thus avoiding the need to chmod it.
Paul.
10:35 p.m.
On Wed, 2006-03-01 at 22:05 +0200, Ville Skyttä wrote:
On Wed, 2006-03-01 at 17:26 +0000, Paul Howarth wrote:
> %global filtered_requires sh -c '%{__perl_requires} "$@" | %{__sed} -e
> "/^perl(unwanted_require)$/d"'
> %define __perl_requires %{filtered_requires}
>
> Anyone see any problems with this?
I don't see any technical problems offhand,
It'll get very ugly if having
to use escapes, and more complex sed
patterns.
but it'll sure get ugly when
one needs to filter many provides/requires because IIRC the whole
"%global ..." shebang needs to be on one line.
I prefer the current
version, because the script inside is
plain /bin/shell without any escapes. This is less error prone in more
complex situations.
The only nastiness about the current implementation, I see, is it
relying on the %define being sequentially expanded inside of the spec.
This is likely to break in rpms which contain subpackages with diverging
"Versions:", similar to
..
Name: a
Version: x
Source0: a-sub1-x.tar.gz
Source1: a-sub2-y.tar.gz
%package sub1
Version: x
%package sub2
Version: y
..
I am facing such kind of %version related issues in a non-perl package,
which applies a customized find-requires, being generated on-the-fly.
Ralf
6631
days inactive
6639
days old
perl-devel@lists.fedoraproject.org
14 comments
5 participants
participants (5)
-
Jason L Tibbitts III -
Paul Howarth -
Ralf Corsepius -
Steven Pritchard -
Ville Skyttä