Regards, Stuart
Michael Jones wrote:
> 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
>
_______________________________________________
LTIB home page: http://ltib.org
Ltib mailing list
address@hidden <mailto:address@hidden>
http://lists.nongnu.org/mailman/listinfo/ltib