Creating a "super rpm" that installs other rpms

[Fred White]

Hello,

I'm creating a "super rpm" which in turn installs other rpms, and executes
a script and performs non-interactive installation (using expect). These
are application specific RPMs and are currently not available in our
rhn/spacewalk channels. These RPMs needs to be installed in a specific
order and some of them also needs to be installed with nodeps (rpm -i
--nodeps), since there are missing dependencies, and there are vendor
instructions to do so.

I'm seeking advise and suggestions on two issues below:

Issue 1) What are general Fedora packaging guidelines around creating such
an RPM? I'm looking to understand what are the caveats
(non-recommendations) to this approach.
  - I'm not adding a list of these RPMs in the %Requires section of the
SPEC file because that requires further modification of the rhn/spacewalk
channels.
  - RPM installation will be done in the %install section and the script
will be run in the %postinstall using expect (haven't looked at this yet)

Issue 2) I went ahead and built this anyway. Please fine snippet from the
SPEC file and output here:

http://fpaste.org/fuK4/

I'm not clearing RPM_BUILD_ROOT in my install section, but while building
it clears it anyway, hence my installation fails since there are not rpms
there at that time. Is this normal?

So what *should* happen is:

%prep
.. unpacking source
.. cp %(_builddir)/foo %(buildroot)

%install
rpm -ivh a.rpm

But instead:
%prep
.. unpacking source
.. cp %(_builddir)/foo %(buildroot)

%install
rm -rf $RPM_BUILD_ROOT
.. no rpms to install

Any advise and suggestions is highly appreciated. - Thanks!

[yersinia]

On Tue, Dec 18, 2012 at 2:39 AM, Fred White <derfmails08(a)gmail.com&gt; wrote:
>  Hello,
>
>  I'm creating a "super rpm" which in turn installs other rpms, and executes
> a
>  script and performs non-interactive installation (using expect). These are
>  application specific RPMs and are currently not available in our
>  rhn/spacewalk channels. These RPMs needs to be installed in a specific order
>  and some of them also needs to be installed with nodeps (rpm -i --nodeps),
>  since there are missing dependencies, and there are vendor instructions to
>  do so.
>
>  I'm seeking advise and suggestions on two issues below:
>
>  Issue 1) What are general Fedora packaging guidelines around creating such
>  an RPM? I'm looking to understand what are the caveats (non-recommendations)
>  to this approach 
Hi

I doubt that the packaging guideline say something about this. It 's
always been considered wrong by many here to install rpm inside rpm.
However you can see who did it in the past and how, even with yum, if
you search "package bundle" in google. For example, I have done this
in the past, with an ancient rpm version ( rpm 4.4.x).

Best

[Ralf Corsepius]

On 12/18/2012 02:39 AM, Fred White wrote:
>  Hello,
>
>  I'm creating a "super rpm" which in turn installs other rpms, and
>  executes a script and performs non-interactive installation (using
>  expect). These are application specific RPMs and are currently not
>  available in our rhn/spacewalk channels. These RPMs needs to be
>  installed in a specific order and some of them also needs to be
>  installed with nodeps (rpm -i --nodeps), since there are missing
>  dependencies, and there are vendor instructions to do so. 
Do I understand
correctly, you are trying to install rpms from inside 
another one by invoking a script/program or similar?

>  I'm seeking advise and suggestions on two issues below:
>
>  Issue 1) What are general Fedora packaging guidelines around creating
>  such an RPM? 
Such rpms are strictly prohibited.

All rpms are supposed to be pulled-in through Requires: etc.

Ralf

[Matthew Miller]

On Mon, Dec 17, 2012 at 09:39:19PM -0400, Fred White wrote:
>  a script and performs non-interactive installation (using expect).
> These
>  are application specific RPMs and are currently not available in our
>  rhn/spacewalk channels. These RPMs needs to be installed in a specific
>  order and some of them also needs to be installed with nodeps (rpm -i
>  --nodeps), since there are missing dependencies, and there are vendor
>  instructions to do so. 
A "super rpm" is the wrong tool for the job, here. You _could_ do it, but
you really shouldn't. The same goes for those vendor RPMs, which sound
horribly broken.


>  Issue 1) What are general Fedora packaging guidelines around creating
> such
>  an RPM? I'm looking to understand what are the caveats
>  (non-recommendations) to this approach. 
"Don't do it." You're pounding in nails with a Cuisinart.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Greg Swift]

On Mon, Dec 17, 2012 at 9:44 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;wrote:

>  On Mon, Dec 17, 2012 at 09:39:19PM -0400, Fred White wrote:
>  > a script and performs non-interactive installation (using expect). These
>  > are application specific RPMs and are currently not available in our
>  > rhn/spacewalk channels. These RPMs needs to be installed in a specific
>  > order and some of them also needs to be installed with nodeps (rpm -i
>  > --nodeps), since there are missing dependencies, and there are vendor
>  > instructions to do so.
>
>  A "super rpm" is the wrong tool for the job, here. You _could_ do it, but
>  you really shouldn't. The same goes for those vendor RPMs, which sound
>  horribly broken. 

As someone that has had to deal with several this kind of broken package, I
can honestly say your life will be better if you just repackage their
RPMs.  Its ugly, but you can just extract their RPMs in your spec file.

Also, yell at your vendor. :)  nicely of course (but it doesn't hurt to be
a broken record). Making sure they know their process is broken and that
there is a community of people can answer questions and help them make it
better.

[Chun Tat David Chu]

I have encounter similar scenario, and like everyone else said, installing
RPMs within a RPM is strongly discourage.

Anyway, the end result I use is a mixtures of 'requires', 'prereqs' and
'triggers' tags in the spec.

The 'prereqs' and 'requires' tag allows you to ensure package install
order.  Assuming you list out all your dependency then your RPM wouldn't be
allow to install if other required RPMs didn't get install first.
http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html

The 'triggers' tag allows you to handle the case where a per-requisite
package already installed.
http://rpm.org/api/4.4.2.2/triggers.html

I believe the 'prereqs' tag has been deprecated in newer version of RPM.
If you would like to go that route then do a research and see what's the
current approach.

Good luck,

dc

On Mon, Dec 17, 2012 at 11:07 PM, Greg Swift <gregswift(a)gmail.com&gt; wrote:

>  On Mon, Dec 17, 2012 at 9:44 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;wrote:
>
> > On Mon, Dec 17, 2012 at 09:39:19PM -0400, Fred White wrote:
> > > a script and performs non-interactive installation (using expect). These
> > > are application specific RPMs and are currently not available in our
> > > rhn/spacewalk channels. These RPMs needs to be installed in a specific
> > > order and some of them also needs to be installed with nodeps (rpm -i
> > > --nodeps), since there are missing dependencies, and there are vendor
> > > instructions to do so.
> >
> > A "super rpm" is the wrong tool for the job, here. You _could_ do it, but
> > you really shouldn't. The same goes for those vendor RPMs, which sound
> > horribly broken.
>
>
>  As someone that has had to deal with several this kind of broken package,
>  I can honestly say your life will be better if you just repackage their
>  RPMs.  Its ugly, but you can just extract their RPMs in your spec file.
>
>  Also, yell at your vendor. :)  nicely of course (but it doesn't hurt to be
>  a broken record). Making sure they know their process is broken and that
>  there is a community of people can answer questions and help them make it
>  better.
>
>  --
>  packaging mailing list
>  packaging(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/packaging
>

[Miroslav Suchý]

On 12/18/2012 02:39 AM, Fred White wrote:
>  I'm creating a "super rpm" which in turn installs other
> rpms, and
>  executes a script and performs non-interactive installation (using
>  expect). These are application specific RPMs and are currently not
>  available in our rhn/spacewalk channels. These RPMs needs to be
>  installed in a specific order and some of them also needs to be 
Just create rpm which just contains script:
   your-product-configure
and do all that work there. Do not try to do that in %install.
And in that script do all that "spacewalk-channel --add" and you can 
even be interactive there if you want to (you could not be interactive 
in %install).

>  installed with nodeps (rpm -i --nodeps), 
nodeps in production is highway to hell.

Of course such package could not get into Fedora until you get there all 
dependecies, but I have feeling, that this is not your goal.

-- 
Miroslav Suchy
Red Hat Systems Management Engineering