BTW: the dependency stuff in LTIB is deliberately loose. The reason
being that it's intended that people are developing packages and that
they can get them to install/build etc despite not being able to fulfil
(all) dependencies. In fact you can add builddeps and deps to the rpm
spec files now, but you may notice in some cases these have been
deliberately removed. As always this is a balancing act. I guess what
would be nice would be to turn this on and off dynamically, but again
more work/time.
Thanks for the ideas, they are appreciated.
Regards, Stuart
Peter Barada wrote:
> On Fri, 2009-11-20 at 13:29 +0000, Stuart Hughes wrote:
>> Hi Peter,
>>
>> Thanks a good idea. I think it may take some effort to get in and fully
>> tested though. I'll keep that in mind and look into adding this when I
>> can get to it.
>
> I'll be glad to help test such.
>
> I know I'm in a breadline begging for toast, but I was originally
> thinking of a more descriptive dependency syntax(so users don't need to
> know perl) that is run through a tool that generates the perl dependency
> ists. Here's an example of the syntax (using some of the dependencies
> out of ltib 9.4.1, and adding my own at the end). By extension, the
> builtin dependencies can be stated in this manner as well:
>
> PKG_U_BOOT:
> config depends on PKG_U_BOOT_CONFIG_TYPE, PKG_U_BOOT_BUILD_ARGS
> config depends on PKG_U_BOOT_LEAVESRC
>
> PKG_KERNEL:
> config depends on PKG_KERNEL_PRECONFIG PKG_KERNEL_WANT_HEADERS
> config depends on PKG_KERNEL_WANT_CF, PKG_KERNEL_LEAVESRC,
> SYSCFG_DTC_NAME
> config depends on SYSCFG_CUIMAGE
> build depends on PKG_MODEPS
>
> PKG_SKELL:
> config depends on PKG_SKELL_WANT_TERMINFO
> build depends on PKG_SYSCONFIG
> install depends on PKG_SYSCONFIG
>
> PKG_MERGE:
> build depends on PKG_MODEPS
>
> # with a local change to /etc/issues (to change the platform banner), need
> # to reinstall merge if skell is installed (merger copy of /etc/issues
> trumps skell's)
> PKG_MERGE:
> install depends on PKG_SKELL
>
>
> Then LTIB can run the tool over the common/platfomr dependency file(s)
> which spits out a perl version of $paltform_config_deps,
> $platform_build_deps, $platform_install_deps, and then pull in the
> result. A simple existence/date comparison on the dependency file and
> resultant output drives whether the tool needs to be run.
>
> I figure I can whip up something using flex/yacc within a couple of
> hours, assuming the syntax of the output of the tool whould look like
> the current current $config_dep, $build_dep, and $install_dep hashes.
>
>> 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> <mailto:address@hidden>
<mailto:address@hidden>
>> >> http://lists.nongnu.org/mailman/listinfo/ltib
>> > --
>> > Peter Barada <address@hidden <mailto:address@hidden> <mailto:address@hidden> <mailto:address@hidden>>
>> > Logic Product Development, Inc.
>> >
> --
> Peter Barada <address@hidden <mailto:address@hidden> <mailto:address@hidden>>
> Logic Product Development, Inc.
>