RPM rebuild made easier?

[Joel Sherrill]

Thomas Doerfler wrote:
> 
> Hello Ralf,
> > >
> > > So here is my request: Would it be possible to replace the
> > > "_prefix" definition in the specs from
> > >
> > > %define _prefix   /opt/rtems
> > >
> > > to something like:
> > >
> > > %define _prefix   %{?prefix:%prefix}%{!?prefix:/opt/rtems}
> > >
> > > (Ralf, is this correct?
> > Not quite.
> >
> > Syntactically it is correct (I am using similar constructs in many
> of my
> > rpms), but
> > * %prefix has a special meaning inside of rpm-specs:
> > - %prefix is the relocation prefix, also used by rpm/rpmbuild
> --prefix;
> > - %prefix defaults to %_prefix, so your %define above is circular
> > => I am not sure about the potential side-effects
> >
> > * changing %_prefix or %_prefix doesn't help much wrt. parallel
> > installation. You'd also have to change the package %name.
> Well, I think the package name is not a problem. What I don't like
> (but accept) with the OAR packages, is that DIFFERENT packages (in my
> view) like
> i386-rtems-binutils-2.10.rpm
> and
> i386-rtems-binutils-2.13.2.rpm
> would install into the same location /opt/rtems/bin*
> while I would like them to be in different locations:
> /opt/rtems/binutils-2.10-gcc-3.0*
> and
> /opt/rtems/binutils-2.13.2-gcc-3.2*
> Hm. or are you talking about the case that the same binutils package
> version is used together with different gcc/newlib versions? This
> would lead to paths of:
> /opt/rtems/binutils-2.10-gcc-3.0*
> /opt/rtems/binutils-2.10-gcc-3.2*
> and probably this would confuse RPM (am I right here? Sometimes I am a
> bit slow :-( )
> I am not quite sure how this can be overcome, but I think the idea of
> my initial proposal work for most cases (in fact for me and many rtems
> users it is sufficent to switch versions after half a year, not half a
> week like you and Joel might do it...)
> So let's refine my proposal to use a better name instead of "prefix":
> replace from:
> %define _prefix   /opt/rtems
> to
> %define _prefix
> %{?custom_prefix:%custom_prefix}%{!?custom_prefix:/opt/rtems}
> Any further comments?

ALthough this may result in RPMS that have different install points, it
doesn't solve the problem that the packages conflict.  You can't install
"group rtems package binutils X" and "group rtems package binutils Y".
RPM will complain.  I think that for this to work you have to override
at least the group and prefix.  Otherwise RPM will think they are the
same package.


> Thomas.
> > >  Any improvements possible?
> > Of cause ;)
> >
> > For the moment, there is an easier way to apply a different
> installation prefix:
> >
> > In RTEMS source tree,
> > cd scripts
> > ../bootstrap
> > ./configure --prefix=/opt/rtems-4.6
> > make
> >
> > The rpm-specs generated then will apply /opt/rtems-4.6 instead of
> > /opt/rtems.
> >
> > > The anybody who wants to rebuild the toolset simply has to
> > > call RPM as follows:
> > >
> > >
> > > $ rpm -ba --define 'prefix /opt/rtems/binutils-2.13.2.1-gcc-
> > > 3.2.1-newlib-1.11.0' --define 'gnat 0' --define 'gcj 0'
> > > powerpc-rtems-gcc-3.2.1-newlib-1.11.0.spec
> > >
> > > No more hacking around inside the specs...
> > You've just discovered, why it is implemented the way it is.
> >
> > Except of the prefix you are using, it's exactly what I am using for
> > speeding up testing the rpms.
> >
> > > Is it possible to integrate this into the toolse specs?
> >
> > Ralf
> >
> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available at: http://www.imd-
> systems.de/pgp_keys.htm

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985