Re: src.rpm for x86_64

[Carl Nygard <cjnygard fast net>]

One more time...

Now that I browsed through the /usr/lib/rpm/x86_64-linux/macros file, I
see the following definition:

%__os_install_post    \
    /usr/lib/rpm/brp-compress \
    /usr/lib/rpm/brp-strip \
    /usr/lib/rpm/brp-strip-static-archive \
    /usr/lib/rpm/brp-strip-comment-note \
%{nil}
                                                                                
This tell me where the brp-compress is coming from.  It also indicates
that it's probably not so bad to hardcode the path to brp-compress,
since that's hardcoded in the ./rpm/<platform>-linux/macros file.

So I propose the following patch instead:

-[ -x %{_libdir}/rpm/brp-compress ] && %{_libdir}/rpm/brp-compress
+[ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress

This seems to work on x86_64, and I'd assume it works on i386, since the
path is hardcoded in ./rpm/i[3456]86-linux/macros as well.

If you want me to generate real patches for all the spec.in files, I can
do that as well.  But I'm betting they will all be the same boilerplate
fix.

Regards,
Carl

On Wed, 2004-10-20 at 15:21, Carl Nygard wrote:
> And now I'm really confused.  my /usr/lib/rpm/macros defines _lib="lib",
> but running the rpmbuild process with a simple 'echo lib=%{_lib}' shows
> lib64 as the result.
>
> So somewhere _lib is getting redefined, and I can't see where.  Not
> anywhere (that I know) in /usr/lib/rpm or in /etc/rpm.
>
> Now I'm clueless, the only solution I can see is either:
>
> sudo ln -s /usr/lib/rpm /usr/lib64/rpm
> or hardcode the path to brp-compress in the %install portion of the spec
> file.
>
> ln -s will work for me temporarily
>
>
> Just figure out, there's architecture-specific subdir with it's own
> macro redefinitions.  Mystery solved, but still no good solution.
>
> On Wed, 2004-10-20 at 14:45, Ross McFarland wrote:
> > Carl Nygard said:
> > > Processing files: perl-ExtUtils-Depends-0.204-1
> > > error: File not found:
> > > /var/tmp/perl-ExtUtils-Depends-0.204-1-root/usr/share/man/man3/ExtUtils::Depends.3pm
> > >
> > > Finally found the docs where the macros are defined (that was way too
> > > hard).
> > >
> > > The only thing I can come up with is to do this:
> > >
> > > -[ -x %{_libdir}/rpm/brp-compress ] && %{_libdir}/rpm/brp-compress
> > > +[ -x %{_prefix}/%{_lib}/rpm/brp-compress ] &&
> > > %{_prefix}/%{_lib}/rpm/brp-compress
> >
> > i suspect this is just preventing brp-compress from running. -x ... will
> > likely fail b/c i don't think brp-compress will be in _prefix..., the location
> > into which the rpm is building.
> >
> > i'm not 100% that line should be in there, at least i don't know off hand what
> > it does. it was probably in the examples i based our spec files off of so i
> > left it alone. what happens if you totally remove it?
> >
> > > I think there's something wrong with using brp-compress behind your back
> > > when it changes filenames on you.  That's either a bug or my complete
> > > ignorance.
> >
> > the next two lines are building up the filelist on the fly using the find
> > command:
> >
> > find $RPM_BUILD_ROOT%{_prefix} -type f -print | \
> >     sed "s ^$RPM_BUILD_ROOT@@g" > %{name}-%{version}-%{release}-filelist
> >
> > that should have the correct extensions reguardless of what then ended up
> > being. (changed or not) it builds the list after brp-compress has been run.
> > i'm not sure how that could end up with invalid file names. i think something
> > bigger is going on here.
> >
> > -rm
> > _______________________________________________
> > gtk-perl-list mailing list
> > gtk-perl-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gtk-perl-list
>
> _______________________________________________
> gtk-perl-list mailing list
> gtk-perl-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list