[Buildroot] How to provide one default skeleton per init system?

[Buildroot] How to provide one default skeleton per init system?

[Eric Le Bihan]

Hi!

To properly use systemd as init system, some modifications should be performed
on the default skeleton. This can be done via an overlay and a post-build
script, as done in [1]. However, it would be best for Buildroot users to have
it done automatically, as noted per ThomasP and MaximeH [2]. This brings forth
the idea of having one target skeleton per init system.

IHMO, there are two solutions for implementing it:

a) Move system/skeleton to system/skeleton/busybox, then add
   system/skeleton/systemd, and maybe system/skeleton/sysv. The menu in
   system/Config.in will be updated to select BR2_ROOTFS_SKELETON_BUSYBOX,
   or BR2_ROOTFS_SKELETON_CUSTOM.
b) Add a new virtual package: target-skeleton, with some providers:
   target-skeleton-busybox, target-skeleton-systemd and
   target-skeleton-custom (path to the custom skeleton would be handled in the
   configuration menu).

Solution A is the quickest and less intrusive to implement, but it can only
copy the files of the skeleton, not perform the additional operations from the
post-build script. So solution B seems the best.

But if a new package target-skeleton is added, what would be the dependency
chain? Would `make target-skeleton-rebuild` rebuild... the whole rootfs?

Comments and ideas welcomed!

Best regards,
ELB

[1] https://github.com/elebihan/buildroot-ext-elb/tree/master/overlays/base-systemd
[2] http://lists.busybox.net/pipermail/buildroot/2014-June/098738.html

[Buildroot] How to provide one default skeleton per init system?

[Maxime Hadjinlian]

Hi Eric, all

On Mon, Jun 9, 2014 at 11:13 PM, Eric Le Bihan
<eric.le.bihan.dev@free.fr> wrote:
> Hi!
>
> To properly use systemd as init system, some modifications should be performed
> on the default skeleton. This can be done via an overlay and a post-build
> script, as done in [1]. However, it would be best for Buildroot users to have
> it done automatically, as noted per ThomasP and MaximeH [2]. This brings forth
> the idea of having one target skeleton per init system.
Exactly, and I have started a few patches to do so. I shall send them
pretty soon and break my series in too so that this part is at least
done.
>
> IHMO, there are two solutions for implementing it:
>
> a) Move system/skeleton to system/skeleton/busybox, then add
>    system/skeleton/systemd, and maybe system/skeleton/sysv. The menu in
>    system/Config.in will be updated to select BR2_ROOTFS_SKELETON_BUSYBOX,
>    or BR2_ROOTFS_SKELETON_CUSTOM.
> b) Add a new virtual package: target-skeleton, with some providers:
>    target-skeleton-busybox, target-skeleton-systemd and
>    target-skeleton-custom (path to the custom skeleton would be handled in the
>    configuration menu).
>
> Solution A is the quickest and less intrusive to implement, but it can only
> copy the files of the skeleton, not perform the additional operations from the
> post-build script. So solution B seems the best.
>
> But if a new package target-skeleton is added, what would be the dependency
> chain? Would `make target-skeleton-rebuild` rebuild... the whole rootfs?
>
Actually the package that I have introduced after discussing it with
Thomas Petazzoni was a package called initscripts and busybox/systemv
only depends on it. This way, when you chose an init system, it will
copy the files to the target directory.

This seems to be less intrusive as the end users would not even notice
(except the disappearance of the init.d folder when systemd is
chosen).

If you have any comments regarding this idea, they are welcomed.
I'll try and send this patch tonight so we can discuss on the idea
with some code.
> Comments and ideas welcomed!
>
> Best regards,
> ELB
>
> [1] https://github.com/elebihan/buildroot-ext-elb/tree/master/overlays/base-systemd
> [2] http://lists.busybox.net/pipermail/buildroot/2014-June/098738.html
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] How to provide one default skeleton per init system?

[Thomas Petazzoni]

Dear Maxime Hadjinlian,

On Tue, 10 Jun 2014 09:21:39 +0200, Maxime Hadjinlian wrote:

> > But if a new package target-skeleton is added, what would be the dependency
> > chain? Would `make target-skeleton-rebuild` rebuild... the whole rootfs?
> >
> Actually the package that I have introduced after discussing it with
> Thomas Petazzoni was a package called initscripts and busybox/systemv
> only depends on it. This way, when you chose an init system, it will
> copy the files to the target directory.
> 
> This seems to be less intrusive as the end users would not even notice
> (except the disappearance of the init.d folder when systemd is
> chosen).
> 
> If you have any comments regarding this idea, they are welcomed.
> I'll try and send this patch tonight so we can discuss on the idea
> with some code.

After thinking more about it, I believe it would be even better to have
the whole skeleton as a package. This way, everything installed to
$(TARGET_DIR) comes from a package, and things like my "graph-size"
script do not need to special case the skeleton.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] How to provide one default skeleton per init system?

[Jérôme Pouiller]

Hello,

On Tuesday 10 June 2014 11:50:04 Thomas Petazzoni wrote:
> Dear Maxime Hadjinlian,
> 
> On Tue, 10 Jun 2014 09:21:39 +0200, Maxime Hadjinlian wrote:
> > > But if a new package target-skeleton is added, what would be the
> > > dependency
> > > chain? Would `make target-skeleton-rebuild` rebuild... the whole rootfs?
> > 
> > Actually the package that I have introduced after discussing it with
> > Thomas Petazzoni was a package called initscripts and busybox/systemv
> > only depends on it. This way, when you chose an init system, it will
> > copy the files to the target directory.
> > 
> > This seems to be less intrusive as the end users would not even notice
> > (except the disappearance of the init.d folder when systemd is
> > chosen).
> > 
> > If you have any comments regarding this idea, they are welcomed.
> > I'll try and send this patch tonight so we can discuss on the idea
> > with some code.
> 
> After thinking more about it, I believe it would be even better to have
> the whole skeleton as a package. This way, everything installed to
> $(TARGET_DIR) comes from a package, and things like my "graph-size"
> script do not need to special case the skeleton.

Hmm... This patch seems to be something close to that:
  http://patchwork.ozlabs.org/patch/335963/

I may rework it, if needed.


-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr

[Buildroot] How to provide one default skeleton per init system?

[Thomas Petazzoni]

Dear Eric Le Bihan,

On Mon, 9 Jun 2014 23:13:43 +0200, Eric Le Bihan wrote:

> To properly use systemd as init system, some modifications should be performed
> on the default skeleton. This can be done via an overlay and a post-build
> script, as done in [1]. However, it would be best for Buildroot users to have
> it done automatically, as noted per ThomasP and MaximeH [2]. This brings forth
> the idea of having one target skeleton per init system.

Right. This looks a necessary cleanup to me.

> IHMO, there are two solutions for implementing it:
> 
> a) Move system/skeleton to system/skeleton/busybox, then add
>    system/skeleton/systemd, and maybe system/skeleton/sysv. The menu in
>    system/Config.in will be updated to select BR2_ROOTFS_SKELETON_BUSYBOX,
>    or BR2_ROOTFS_SKELETON_CUSTOM.
> b) Add a new virtual package: target-skeleton, with some providers:
>    target-skeleton-busybox, target-skeleton-systemd and
>    target-skeleton-custom (path to the custom skeleton would be handled in the
>    configuration menu).
> 
> Solution A is the quickest and less intrusive to implement, but it can only
> copy the files of the skeleton, not perform the additional operations from the
> post-build script. So solution B seems the best.
> 
> But if a new package target-skeleton is added, what would be the dependency
> chain? Would `make target-skeleton-rebuild` rebuild... the whole rootfs?

Clearly, some sort of solution (b), i.e something based on packages.

Regarding the names, I'd use just skeleton-*, not target-skeleton-*.
And I believe I would make skeleton a virtual package provided by
skeleton-systemd and skeleton-busybox, but instead have the 'skeleton'
package be a real package that provides all the files common to both
the Busybox and Systemd cases, and then have skeleton-systemd and
skeleton-busybox depend on skeleton, and adding the additional stuff
needed by systemd or busybox.

Also, there is the case of sysvinit, which is another init system that
we support.

Regarding the dependency chain, I believe all target packages will have
to depend on 'skeleton-<init>', just like they all depend on the
'toolchain' package. Since 'skeleton-<init>' are also going to be
target packages, it will require a little trick to avoid the circular
dependency, but nothing really terrible here.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] How to provide one default skeleton per init system?

[Maxime Ripard]

Hi,

On Mon, Jun 09, 2014 at 11:13:43PM +0200, Eric Le Bihan wrote:
> Hi!
> 
> To properly use systemd as init system, some modifications should be performed
> on the default skeleton. This can be done via an overlay and a post-build
> script, as done in [1]. However, it would be best for Buildroot users to have
> it done automatically, as noted per ThomasP and MaximeH [2]. This brings forth
> the idea of having one target skeleton per init system.
> 
> IHMO, there are two solutions for implementing it:
> 
> a) Move system/skeleton to system/skeleton/busybox, then add
>    system/skeleton/systemd, and maybe system/skeleton/sysv. The menu in
>    system/Config.in will be updated to select BR2_ROOTFS_SKELETON_BUSYBOX,
>    or BR2_ROOTFS_SKELETON_CUSTOM.
> b) Add a new virtual package: target-skeleton, with some providers:
>    target-skeleton-busybox, target-skeleton-systemd and
>    target-skeleton-custom (path to the custom skeleton would be handled in the
>    configuration menu).

And you also have:

  c) Move the files in the skeleton at the package level. Each package
     would be providing whatever file it needs and is not shared by
     all the init systems.

> Solution A is the quickest and less intrusive to implement, but it can only
> copy the files of the skeleton, not perform the additional operations from the
> post-build script. So solution B seems the best.

And solution C would be taking the advantages of both. It's not very
intrusive, since everything is already in place, and you can do pretty
much anything you want.

> But if a new package target-skeleton is added, what would be the dependency
> chain? Would `make target-skeleton-rebuild` rebuild... the whole rootfs?

And you don't have to worry about the dependencies either.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140610/15468d61/attachment.asc>

[Buildroot] How to provide one default skeleton per init system?

[Thomas Petazzoni]

Dear Maxime Ripard,

On Tue, 10 Jun 2014 10:01:23 +0200, Maxime Ripard wrote:

> > a) Move system/skeleton to system/skeleton/busybox, then add
> >    system/skeleton/systemd, and maybe system/skeleton/sysv. The menu in
> >    system/Config.in will be updated to select BR2_ROOTFS_SKELETON_BUSYBOX,
> >    or BR2_ROOTFS_SKELETON_CUSTOM.
> > b) Add a new virtual package: target-skeleton, with some providers:
> >    target-skeleton-busybox, target-skeleton-systemd and
> >    target-skeleton-custom (path to the custom skeleton would be handled in the
> >    configuration menu).
> 
> And you also have:
> 
>   c) Move the files in the skeleton at the package level. Each package
>      would be providing whatever file it needs and is not shared by
>      all the init systems.

I don't think (b) and (c) are mutually exclusive actually. We can
have a "skeleton" package that installs all the files that are common
to all situations, and then have busybox, systemd and sysvinit install
the files that they need.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com