Regards, Stuart
Peter Barada wrote:
> On Thu, 2009-11-19 at 09:42 +0000, Stuart Hughes wrote:
>> Hi Michael,
>>
>> I see the issue and I think I ran into this before and decided there's
>> no right answer here, just choices. Although merge could be triggered
>> by and package build, this could get annoying in the general case. The
>> ideal behaviour would be if could only re-installed merge if one of the
>> files in that package had been re-installed (so you could re-stomp).
>> Unfortunately that wouldn't be simple to do.
>>
>> So I think you're right that in the case of merge, you just need to say
>> "if you think you might need merge re-installed, re-run ./ltib -p merge -f).
>>
>> BTW: this is yet another reason why in my opinion merge is a less than
>> idea package. As a general principle BSP packagers should avoid it.
>
> I agree, but "merge" is useful on a per-platform basis to make specific
> modifications to the rootfs can be made w/o having a platform-versioned
> instance of a package to affect the change. For example, its much
> easier to add config/platfomr/__platform__/merge/etc/issues to modify
> the long banner for a platform as opposed to creating a patch to skell
> that modifies /etc/issues, a new skell-__platform__.spec file, and an
> entry in config/platform/__platform__/pkg_map.
>
> To make things easier(and more foolproof) to use merge, perhaps the
> dependency for merge can be expressed on a per-platform basis?
> How hard would it be to read in an addition to $install_deps from a
> platform-specific file (say config/platform/__platform__/dependencies)?
> Then if the platform has merge entries that overwrite a portion of the
> skel package(as in the above example), the dependency can be expressed:
>
> $platform_install_deps = { PKG_MERGE => [ qw/PKG_SKEL/ ],
> };
>
> Or if the platform adds in packages that are specific to the platform,
> then inter-package dependcies can be expressed.
>
> This concept can be extended to include platform-specific additions to
> $config_deps and $build_deps as well...
>
>> 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
> --
> Peter Barada <address@hidden <mailto:address@hidden>>
> Logic Product Development, Inc.
>