[OE-core] RFE: make the init manager an image feature (again)

Sun Feb 24 14:10:29 UTC 2013

On Sun, Feb 24, 2013 at 5:50 AM, Khem Raj <raj.khem at gmail.com> wrote:
> On (16/02/13 11:41), Otavio Salvador wrote:
>> On Sat, Feb 16, 2013 at 10:53 AM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>> > On Sat, 2013-02-16 at 08:47 -0200, Otavio Salvador wrote:
>> >> On Sat, Feb 16, 2013 at 7:15 AM, Richard Purdie
>> >> <richard.purdie at linuxfoundation.org> wrote:
>> >> > On Fri, 2013-02-15 at 19:19 +0100, Enrico Scholz wrote:
>> >> >> it would be nice when the decision to make the init manager a distribution
>> >> >> feature will be reverted to the old oe-meta mechanism.
>> >> >>
>> >> >> Being a distribution feature means, that packages are created in such a
>> >> >> way that it is impossible to split off unwanted and heavy weighted
>> >> >> functionality at image creation time.
>> >> >>
>> >> >> E.g. on most of my systems, I create two kinds of images: a full
>> >> >> featured, systemd based one and a very minimal rescue system with
>> >> >> busybox and some filesystem utilities.  With recent systemd packaging
>> >> >> change, the rescue image size grow up from 5.9 MiB to 27 MiB because
>> >> >> systemd dependencies are hardcoded in mandatory packages.
>> >> >>
>> >> >> Formerly, systemd dependencies could be avoided by adding the -systemd
>> >> >> packages to BAD_RECOMMENDATIONS (e.g. due to busybox-syslog ->
>> >> >> busybox-syslog-systemd rrecommend).
>> >> >>
>> >> >> I am aware that initscripts were always part of the main package.  But
>> >> >> sysvinit was very lightweighted and the extra space either negligible or
>> >> >> easy to recover by removing some files in IMAGE_PREPROCESS_COMMAND.
>> >> >>
>> >> >> Hence my recommendation: make the init manager an image feature again
>> >> >> and create -systemd and -sysv packages with the corresponding scripts.
>> >> >> OpenEmbedded is still for embedded devices where size matters.
>> >> >>
>> >> >> Of course, systemd can be still a distribution feature to enable things
>> >> >> like socket activation as part of PACKAGE_CONFIG.  But dependencies on
>> >> >> init system packages should be RRECOMMENDS which can be overridden
>> >> >> easily at image creation time.
>> >> >
>> >> > The trouble is that by making it an "image feature", people will expect
>> >> > *everything* to work properly and to be able to have fully functional
>> >> > sysvinit and systemd variants of images. We already see this
>> >> > expectation. Trying to explain to people what the limitations are, what
>> >> > is expected to work and what isn't will be difficult. I know you
>> >> > understand this but going forward most people will simply not and I
>> >> > think it will be a nightmare for usability.
>> >>
>> >> You said you already see it so what is the change? For me less
>> >> flexibility is more problem and the result are more ugly hacks. I've
>> >> been using the systemd system in meta-oe in product for long time and
>> >> it works fine. In same distro I build other product with is sysvinit
>> >> based and it also works fine.
>> >>
>> >> Now I have a nightmare in upgrade path, a change in the way my
>> >> customer work and as a plus the need to make two different
>> >> distributions for same product. No sense to me.
>> >>
>> >> Final result? This product won't go out of danny as I won't be able to
>> >> provide an usable upgrade path without forking OE or having an insane
>> >> amount of bbappend hacks.
>> >
>> > When systemd was added to meta-oe, it was clearly mentioned that it was
>> > a proof of concept to experiment with integrating it and subject to
>> > change until it made it into OE-Core. The fact is is changing is
>> > therefore not a surprise. We do need to think about making sure we have
>> > equivalent functionality, we also need to think about migration but the
>> > fact changes happened with some experimental work should not surprise
>> > people. I appreciate that isn't ideal but it is the way it is.
>>
>> Sure; I'd expect a change for the better ... besides all the work done
>> in meta-oe lead it to a proper and good implementation (having it
>> being split and drop the contamination of images we had first
>> implementation). Having it as a distro feature is a good option too
>> but all package split, logic and implementation of rest were good and
>> flexible.
>>
>> >> > For that reason I'd rather see this done in a different way, for example
>> >> > blacklisting the problematic systemd dependencies at image generation
>> >> > time with some kind of stronger BAD_RECOMMENDS code. Yes, this means
>> >> > there would be some systemd config files lying around but you'd stop the
>> >> > main bulk of it coming in (and as you said, some small config files
>> >> > aren't an issue).
>> >>
>> >> Check the amount of changes for do_install_append has sent today. This
>> >> was all not need with the code we had and which works fine. This is
>> >> just duplicated code all over recipes. Seriously the systemd
>> >> integration was done in complete wrong way in my POV. It broght up
>> >> problems we have fixed and do major improvements in meta-oe ... at no
>> >> profit.
>> >
>> > Sorry you feel that way. I'm equally frustrated with the way systemd was
>> > added to meta-oe and the damage it did to the overall usability of the
>> > OE ecosystem. I'm trying to take positive actions from that such as
>> > ensuring we never do something like it again.
>>
>> Agreed. This was fix when we moved it to meta-oe/meta-systemd.
>>
>> > As for the integration into the core, I haven't been too involved with
>> > that and perhaps I should be. The trouble is I alone don't scale and I'm
>>
>> Agreed. Another problem is I didn't see *any* public discussion how it
>> would be done *before* the patchsets. The patchset were done and post
>> as RFC but I'd expect a wider discussion on how it would and should be
>> done before it.
>>
>> > trying to ensure we have more people taking on this kind of work. This
>> > means letting others take it on and learn. There is a requirement from
>> > the community to ensure people working on improvements like this have
>> > all the needed data and that is something which I don't think happened
>> > well here. My point is that I think there have been failings in various
>> > places and the community needs to take some responsibility too.
>>
>> Agreed. But bear on mind I complained in mailing list about this in
>> past (when the systemd patchset were send so it not new I'd prefer it
>> in another way).
>>
>> http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/31067/focus=31090
>>
>> > On the specifics of the do_install_append, you've seen my comments about
>> > how we're not learning from past mistakes with the way the do_install in
>> > the class was written. I note Phil also agreed with them, both of us
>> > remembering some of the horrors we've dealt with in the past (and
>> > binconfig.bbclass is still around, sadly).
>>
>> So you prefer same code to copy same type of files all over the recipes?
>
> duplicating usecase is better even though it may sound
> copying here now think if you add this to a bbclass and works ok for
> a package where we glue the unitfiles fast forward 6mos and the next
> version of the package has added the unitfiles into the package itself
> since systemd is so cool. We will be silently installing our own
> unit files without knowing. Worst if the files from package are
> different. Having individual install append gives you an opportunity
> to delete this append once the package gets its own support for systemd
> and you can easily migrate as the systemd support comes in.

I fail to see how duplicating the code helps to spot the new package
would have the service files. You'll keep installing them until you
discover it has the services files there.

>> > One of the goals of OE-Core is to improve quality. I appreciate in this
>> > case you disagree about the "quality" of those bbappends but I still
>> > believe that approach will be better in the long term as upstream
>> > software starts shipping systemd support. Short term its uglier, I
>> > totally agree. Part of my role in things is to look beyond the short
>> > term, even if people don't want to hear that.
>>
>> Quality is relative. For me avoid code duplication is one of quality
>> aspects I like.
>
> yes it is. But this just isnt the case where it weighs more.

That's way I said it is relative. All depends on which quality aspect
you're thinking about.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br