On 07/02/12 07:55, Otavio Salvador wrote:
On Tue, Feb 7, 2012 at 13:12, Andreas Müller
<schnitzelt...@googlemail.com>wrote:
* These are my first python experiences - suggestions welcome.
* In local.conf (or in distro) the configuration variable INIT_MANAGER
selects
the initmanager to be build into an image. When changing the selection,
a build from scratch is required. INIT_MANAGER currently defaults to
systemd
(see image.bbclass and initmanager.bbclass)
* In systemd.bbclass debug messages were left in to have a better overview
what's going on.
* An additional patch series goes out for meta-angstrom.
* This is a huge RFC which might cause serious impacts. What I have already
detected after a build from scatch is that /var/lib/opkg is missing in the
image (although it can be found in libopkg.ipk). I will spend the next
days with my new friend buildhistory (thanks for this!!).
I've looked at your changes and they does seem to be a good base for
further work:
I agree, good job!
* The init system ought to be a DISTRO_FEATURE (as sysvinit ought to be too
IMO)
I know there's some disagreement with the suggestion that the init
system ought to be a DISTRO_FEATURE but my (admittedly uninformed)
opinion is that I can't see how we can avoid it.
It looks like systemd provides various interfaces and API's that
packages may or may not use and as more packages adopt these we're going
to need to be able to enable/disable more than just some unit
files/scripts for init support.
* I'd like to see sysvinit packages splitted onto ${PN}-sysvinit as well
Agreed. Do we need to think about the case where a systemd based system
might *need* an initscript (no units available) vs. when the -sysvinit
and -systemd packages both provide similar functionality?
Would it be desirable for the rootfs generation logic to be able to fall
back to an alternative "initscript" provider?
* I'd use rootfs generation to install ${PN}-${INIT_SYSTEM} packages for
packages being installed
Thoughts?
Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
