Re: [meta-arago][master/kirkstone][PATCH] arago.conf: make things more readable and fix the virtuals

[Denys Dmytriyenko <denis@denix.org>]

On Mon, Jun 12, 2023 at 11:30:43AM -0500, Andrew Davis wrote:
> On 6/12/23 11:16 AM, Denys Dmytriyenko wrote:
> >On Mon, Jun 12, 2023 at 10:24:27AM -0500, Andrew Davis via lists.yoctoproject.org wrote:
> >>On 6/9/23 3:39 PM, Denys Dmytriyenko wrote:
> >>>On Fri, Jun 09, 2023 at 02:13:23PM -0500, Randolph Sapp via lists.yoctoproject.org wrote:
> >>>>On 6/9/23 13:32, Ryan Eatmon wrote:
> >>>>>
> >>>>>
> >>>>>On 6/6/2023 6:18 PM, Randolph Sapp via lists.yoctoproject.org wrote:
> >>>>>>On 6/6/23 18:15, Randolph Sapp via lists.yoctoproject.org wrote:
> >>>>>>>On 6/6/23 17:15, Denys Dmytriyenko wrote:
> >>>>>>>>On Tue, Jun 06, 2023 at 02:10:19PM -0500, rs@ti.com wrote:
> >>>>>>>>>From: Randolph Sapp <rs@ti.com>
> >>>>>>>>>
> >>>>>>>>>Make things more readable and reliable by useing the built in boolean
> >>>>>>>>>check instead of python's type casting. Drop the array
> >>>>>>>>>indexing in favor
> >>>>>>>>>of a more direct if else statememnt.
> >>>>>>>>
> >>>>>>>>Heh, it's just a matter of personal preference :) Array
> >>>>>>>>indexing conditionals
> >>>>>>>>is how OE used to do things from the early days and I'm well
> >>>>>>>>used to that. But
> >>>>>>>>these days using Python if/else directly gained lots of
> >>>>>>>>traction, so why not?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Also fix the virtual provider for login manager. There
> >>>>>>>>>should only be 1
> >>>>>>>>>login provider and it should be shadow-base for systemd
> >>>>>>>>>*or* busybox for
> >>>>>>>>>sysVinit systemd.
> >>>>>>>>>
> >>>>>>>>>Also explicitly remove the sysvinit distro feature if ARAGO_SYSVINIT
> >>>>>>>>>isn't set, because whatever arago inherits expects sysvinit for some
> >>>>>>>>>reason. This should fix the duplicate init.d and systemd service files
> >>>>>>>>>we've been seeing.
> >>>>>>>>
> >>>>>>>>How much testing have you done with this change?
> >>>>>>>>
> >>>>>>>>The reason it was done this way is because many packages only provided
> >>>>>>>>sysvinit rc scripts and not systemd unit files and we were relying on
> >>>>>>>>systemd-sysv-generator to handle those, which has dependency
> >>>>>>>>on "sysvinit"
> >>>>>>>>PACKAGECONFIG and DISTRO_FEATURES. There were fixes to
> >>>>>>>>handle duplications
> >>>>>>>>when both sysvinit rc script and systemd unit file are
> >>>>>>>>provided by a package
> >>>>>>>>and install only one of them. It was better than not having
> >>>>>>>>any startup script
> >>>>>>>>for a package at all.
> >>>>>>>>
> >>>>>>>
> >>>>>>>Everything in the layers below us provides both from
> >>>>>>>everything I've seen. The only incompliant layers are
> >>>>>>>meta-arago and maybe something in meta-ti still expecting
> >>>>>>>sysVinit scripts.
> >>>>>>>
> >>>>>>>If you set both sysVinit and systemd as a distro feature it
> >>>>>>>actually *confuses* core packages and they end up shipping
> >>>>>>>both, which clash. Systemd typically just resolves this by
> >>>>>>>forcing everything with a sysvinit script into the sysvinit
> >>>>>>>compatibility stage leading to increased boot time because
> >>>>>>>that's all still serialized.
> >>>>>>>
> >>>>>>
> >>>>>>If there are any packages still not compliant that you can find,
> >>>>>>tell me and I will fix them myself. Seeing mix-matched sysVinit
> >>>>>>and systemd scripts in the same target makes me irrationally
> >>>>>>angry.
> >>>>>
> >>>>>Uh oh...  This patch causes tisdk-tiny-image.bb and
> >>>>>tisdk-bootstrap-image.bb to fail:
> >>>>>
> >>>>>ERROR: Nothing RPROVIDES 'packagegroup-arago-sysvinit-boot'
> >>>>>
> >>>>>I think, if I remember correctly, sysvinit was chosen because of a
> >>>>>requirement on the size of the image.  systemd made the rootfs too
> >>>>>big to fit within the constraints.
> >>>
> >>>Ah, indeed, that was another reason systemd and sysvinit had to be both
> >>>enabled in the DISTRO_FEATURES...
> >>>
> >>>
> >>>>>Nishanth might have more details if you want to debate it.  But
> >>>>>there is an internal Confluence page that lists all of the Ease of
> >>>>>Use requirement JIRAs.
> >>>>>
> >>>>>No one is opposed to moving away from sysvinit, but we need to
> >>>>>make sure that we are meeting that requirement.
> >>>>>
> >>>>
> >>>>That's fair. I assumed our sysvinit build images were setting the
> >>>>ARAGO_SYSVINIT variable as part of their base config (or at least
> >>>>something similar).
> >>>
> >>>ARAGO_SYSVINIT flag controls init selection for the main images (default,
> >>>base, thinlinux...), but tiny and bootstrap images ignore it and directly
> >>>pull in SysVinit regardless of the selection.
> >>>
> >>
> >>Default, base, thinlinux, etc.. are rather large images, not sure what
> >>is gained from SysVinit.
> >
> >What is gained is flexibility. When switching to systemd, some customers still
> >wanted to be able to use SysVinit. Not sure if that's still the case though.
> >
> 
> If they want to use sysvinit, then they can modify the distro configs.
> 
> >
> >>And for the super small bring-up images like
> >>bootstrap, we use very little from meta-arago. Would it make more sense
> >>to move those bring-up images out of Arago? Maybe have a small bring-up-
> >>distro layer. Having a distro be both systemd and sysvinit is odd..
> >
> >That would require to build those images separately from the rest of the
> >images and from bundling everything into a single TI SDK tarball. I.e. a
> >multi-step process - build one set of images with one distro, then the
> >rest with a different distro, plus package a bundle tarball. And that will
> >result in a very poor package re-use between the images and 2 flows, since
> >distro-level config changes pretty much invalidate most of shared state...
> >
> 
> Then lets not ship those bring-up images with the SDK tarball then. Those
> are development images, so we should assume folks using them know how to
> build OE.
> 
> I feel like I've suggested this before, I cant figure out what half
> our images are for as is, maybe we try to cut down the number. We could
> also name them to match Ubuntu as the 3 we need have similar uses:
> 
>  * tisdk-default   -> Desktop
>  * tisdk-base      -> Server
>  * tisdk-thinlinux -> IoT

We've been back and forth on this - the number of images grew over time, so 
several years ago we simplified and renamed them and got down to 3 (and there 
should still be internal Confluence pages with that effort, justification and 
reasoning):

tisdk-default
tisdk-base
tisdk-tiny

Then later few more were added - thinlinux, bootstrap and bootstrap-base, and 
there's jailhouse one in the works. I agree there should be better re-use...

-- 
Denys