Re: [Ltib] skell files overwritten by which pkg?

[Michael Jones]

Hi Stuart,

Stuart Hughes wrote:
> Hi Michael,
>
> There are files that deliberately get overwritten by normal package 
> building as you progress.  Skell is just a "good set of defaults" in 
> many cases.  So this behaviour is normal.  To explain this behaviour, 
> think busybox, this provides many utilities, but if you select the 
> full utility (say bash), this will deliberately overwrite the busybox 
> shell.  The same kind of thing applies for skell (and other packages).
>
> Now for this to work properly there are forward and reverse triggers 
> in LTIB.  So if you had bash selected and then de-selected it, LTIB 
> would know to re-install busybox.  However, this only works if you run 
> ./ltib, not ./ltib -p _pkg_.  The -p pkg stuff say "just work on that 
> package".   So in the case of skell you'd be better to do (as a 
> workflow):
>
> ./ltib -p skell -m prep
> edit,edit,edit
> ./ltib
>
> This would cause skell to "build" and the right triggers to apply so 
> that overwriting packages get re-installed.
This work flow isn't working for me. /etc/profile ended up being the one 
from skell and not the one from merge.  After I "edit,edit,edit" in 
rpm/BUILD/skell-1.16/ and do ./ltib, the merge package doesn't get 
reinstalled.  It looks like the skell-to-merge trigger is missing.

Here is some abbreviated output from my ./ltib build: 

$ ./ltib
[...]
Processing: skell-mx
======================
Build path taken because: directory build, no prebuilt rpm,
scbuild/scdeploy already unpacked package
[...]

Processing: skell-mx
======================
Build path taken because: directory build, build key set, no prebuilt rpm,
rpmbuild [...] -bc [...]

Processing: skell-mx
======================
Build path taken because: directory build, build key set, no prebuilt rpm,
rpmbuild [...] -bi [...]

Processing: skell-mx
======================
Build path taken because: directory build, build key set, no prebuilt rpm,
rpmbuild [...] -bb [...]
[...]
sysconfig-mx rebuild forced by skell-mx
sysconfig-mx install forced by skell-mx

Processing: sysconfig-mx
==========================
Build path taken because: build key set,
[...]

Processing: merge
===================

Processing: modeps
====================

Note that sysconfig-mx gets triggered for an install and gets 
reinstalled but merge doesn't.  Looking in ltib, I see that in 
$install_deps, PKG_SKELL triggers PKG_SYSCONFIG but not PKG_MERGE.  This 
makes sense- just adding PKG_MERGE here isn't right because in the 
general case PKG_MERGE could overwrite really any package's files.  I 
suppose for my work flow for now, doing "./ltib -p merge -f" after 
"./ltib" would work.  This problem only jumped out at me originally 
because it changed my prompt, which made me suspicious that I was doing 
something wrong which resulted in other packages also not being 
installed correctly, which doesn't seem to be the case.

Would it make sense to make PKG_MERGE depend on everything?  Or should 
we just say, "Hey, if you want to use merge to stomp on top of already 
installed stuff, that's sloppy and you're responsible for re-installing 
it when necessary"?

-Michael
> So far as your rpm query goes, it does seem possible that /etc/profile 
> is overwritten by the merge package.  In the Savannah CVS I see this:
>
> $ find config/platform/ -name profile
> config/platform/ea3250/merge/etc/profile
> config/platform/imx27ads/merge/etc/profile
> config/platform/imx31ads/merge/etc/profile
>
> NOTE: the merge directories are a way of simply stomping on top of 
> files in the rootfs.  Some BSP packagers use them, personally I 
> believe it's best to avoid them if you can.
>
> Regards, Stuart
>
> Michael Jones wrote:
> > Hi Stuart,
> >
> > In my tinkering with the network configure script, I've stumbled onto 
> > a different problem.  I wanted to modify the /etc/rc.d/init.d/network 
> > script, which belongs to the skell package.  But I noticed that if I do:
> > ./ltib -p skell -m prep
> > <would theoretically make changes here>
> > ./ltib -p skell -m scdeploy
> >
> > ... then some files change, even if I made no chanes to skell.  The 
> > most noticeable was /etc/profile, because this changed the cmd line 
> > prompt.  For example, after a normal LTIB build,
> >
> > ltib$ cat rootfs/etc/profile
> > export PS1='mx31# '
> > export PATH=/usr/bin:/bin:/usr/sbin:/sbin
> > alias ll='ls -l'
> >
> > but after I re-install skell:
> >
> > ltib$ cat rootfs/etc/profile
> > PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin
> > export PATH
> >
> > So obviously this file is normally overwritten or modified by another 
> > package, and by re-installing skell I'm re-overwriting this.  I guess 
> > the relevant question is: what is the right work flow for working on 
> > the skell package?  I'd also like to know how to find out what other 
> > package overwrites this particular file?  I tried:
> >
> > ltib$ /opt/ltib/usr/bin/rpm --root 
> > /home/michael/iMX/eaglevision/ltib/ltib/rootfs --dbpath /var/lib/rpm/ 
> > -qf /etc/profile
> > merge-0.1-1
> > skell-1.16-2
> >
> > but this looks like misinformation to me, since "merge" doesn't touch 
> > /etc/profile.
> >
> > thanks,
> > Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, 
Hans-Joachim Reich