Re: [Ltib] Support for %Post section of .spec file?

[Chip Webb]

Hi Stuart

Thanks for the long and detailed explanation. I really appreciate
your patience with the explanation.

What we need to do is modify/edit files in the root file system prior to
building the initramfs image. And since the files we want to edit are owned
by root, the editing has to be done by root. Furthermore, we have an automatic
build process that requires all steps to be fully automated, so manual
editing of files is not acceptable.

I also understand your desire to prevent people from hosing their own
root file system by running RPM inside a chroot jail. However that is
not so important to us since we use CentOS virtual machines for our builds,
and keep everything for LTIB in a separate subversion server. Doing
our build involves starting up a relatively empty virtual machine, checking
out LTIB from our subversion server and running it. So if we do hose
the host's file system, it's not a big deal.

You list three other options

1. rc.local - Don't think this works because we can't wait till the target boots up.
   
2. merge directory - Not sure this can help us because what we want to do
   isn't replacing one file with another or just adding files to the filesystem.
   
3. separate RPM  - Wouldn't this option suffer from the same chroot limitations
   as I'm trying to solve?

So none of these alternatives would work for us.

It would seem that we have a couple of options

1. Stick with the patch I've made since it works for now.
   Deal with the chroot issue when/if we upgrade to
   a version of LTIB that implements the chroot jail for RPM.
   
2. Write a separate script to run outside of LTIB to fix up
   the file system (sudoing to root). This is doable and is
   what I would have done if I had known it would be so
   difficult to accomplish what I wanted inside of LTIB.
   
3. Build a host-executable version of busybox and place it
   (temporarily) into the chroot jail so that RPM's %post
   and %pre sections can at least run busybox commands
   to edit files (which would be sufficient for us). In that case
   I'd still need the patch I proposed, and then we'd also have
   to build the host-executable busybox package, and
   then find a way to install it ahead of time, and remove it
   before building the initramfs.
   

We are going to stick with #1 for now for the sake of expediency.
We may switch to #2 in the future if we upgrade and that breaks
the build process.

FWIW, we are using a version of LTIB that was packaged last November for
the MPC8544DS evaluation board. Since we're getting ready to
release our product in a month or so, we're not going to update to the
latest version from the CVS repository on savannah in the near future.

Best Regards and thanks again,

Chip Webb


Stuart Hughes wrote:

On Tue, 2008-09-16 at 15:12 -0500, Chip Webb wrote:
  

Hi Stuart,

Thanks again for the quick response. I think we're saying the same
thing, and I agree that it's not possible with the current version of
LTIB
to use a %Post section. The reason is that the build-phase
source .spec file
that is under dist/lfs-5.1/mypackage/mypackage.spec can't run the
%Post section. However, the deploy phase binary .spec file 
(which is automatically created by ltib) can run the %Post section, if
it exists. 
    

No, that's not how it works.  That section you're patching is only for
use with -m scdeploy, which is for single package mode. 


  

So the patch I submitted essentially takes the %Post post section
(if present) from the build-phase .spec file and copies it into the
automatically created deploy-phase .spec file, so that during
the deploy phase, RPM runs the %Post scriptlet when doing the deploy.

    

There is no real deploy phase as you mean it.  -m scdeploy is a mnemonic
to match the real rpm modes -m scbuild -m scinstall.  These let you do
things with rpm without rebuilding everything (and unpacking).  The
deploy phase just does the rpm %install and then actually installs the
rpm on the host in the rootfs are, which is the NFS area for the target
rootfs. 

  

Here's an example. It works with the ltib patch I submitted this
morning.
The example below (which isn't exactly what I'm doing, but serves
to illustrate the point) allows multiple packages to edit a file
called /etc/pkglist.
    

%Post
set -x
echo "<**** Registering mypackage in [target]/etc/pkglist ****>"
cd $RPM_INSTALL_PREFIX/
echo mypackage >> etc/pkglist
      

Which version are you on, I'm surprised that works.  If it's an old one,
then  yes you can do that because it doesn't rely on anything
target-ish.  However it's stuff run by the host.  All you're doing is
taking advantage of the fact the rpm install phase is run as root and
therefore you can do pretty much what you like.  As this is on your host
you can see this is a very bad idea.  LTIB goes to great lengths to make
sure that you can't overwrite host files, this would defeat that.  So
please don't do this.

On later versions of LTIB (current Savannh), you'll see rpms are install
with (for example):

/opt/ltib/usr/bin/rpm --root /home/seh/ltib_bsps/savannah_ltib/rootfs --dbpath /var/lib/rpm --prefix / --ignorearch -ivh --force --excludedocs --define '_tmppath /tmp/ltib' /home/seh/ltib_bsps/savannah_ltib/rpm/RPMS/arm/sysconfig-1.2-1.arm.rpm

The important thing here is that --root <ltib-rootfs> is used.  What
this does is to chroot first to the root directory.  This means that you
can't hose your host filesystem.  However it also means that you would
not be able to run %post, as it would try to start a shell, which unless
the target is the same as the host, will not work.

  

I hope that this helps explain what I'm trying to do.

    

To safely do the same thing (e.g. just modify files), you can either:

1/ use an rc.local
2/ put stuff into a merge directory
3/ have another rpm which places your custom files where you want on the
target system (in the %files section).

Regards, Stuart