Re: [PATCH 1/2] util-linux: disable systemd

Re: [PATCH 1/2] util-linux: disable systemd

[Paulo Neves]

Hello all,

I have the need to enable this services from system. What is the
current status of this circular dependency?
There was talk of coming back to this topic after the milesone but 4
years passed and there was no changes to this topic? Is it still
applicable?

Paulo Neves

Re: [PATCH 1/2] util-linux: disable systemd

[Khem Raj]

> On Feb 24, 2015, at 4:28 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> 
> On Tue, 2015-02-24 at 16:00 -0800, Khem Raj wrote:
>> On Tue, Feb 24, 2015 at 3:32 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
>>> 
>>> In history we have no good example of successfully splitting one piece
>>> of source over multiple recipes, apart from perhaps gcc which we'd all
>>> agree is horrible in a variety of ways. Any time we have attempted this,
>>> we've tended to revert or have calls to revert (e.g. avahi).
>> 
>> I asked for specific problems/issues observed with split builds. I got
>> no concrete examples, yes it has to be done carefully but then I dont
>> think its something that can not be fixed destabilize the release so
>> much. We are building it twice identically and just changing the
>> packaging. In any case, sometimes we should try to tackle the issues
>> out of milestone pressures too.
> 
> You're not building it twice identically, if you were doing that we
> wouldn't have this problem. You're trying to split it into two separate
> chunks and ensuing they are independent, yet they do inter-depend
> correctly when needed too.

yes we are look at

http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/misc&id=c53322e9e587ef9a88c050f21aa98604deeeeb1f

just install and packaging are differing.


> 
> If this is just a packaging problem, we should just ship the extra
> systemd unit parts as part of a separate recipe and then have the main
> util-linux recipe RDEPEND on it.

util-linux provides service files and its better to keep using those for maintenance reasons if we strip them out into auxiliary
packages its same amount of hassle during upgrade as splitting is.

> 
> Specific examples:
> 
> You need to ensure that the PACKAGES generated by both sides of the
> split have consistent naming (maybe overriding and doing what debian
> packaging would have done should the split not been there). The PACKAGES
> need to be careful about the contents of default PN for example. There
> have been issues cleanly separating things into two -dev packages and
> exposing two similar but slightly differently named -dev packages for
> the same piece of software.
> 

there are separate sub-targets which avoids this issue. 

> You have to ensure that the appropriate recipes each register as the
> correct shlibs providers and that things DEPENDing on the recipe now
> depend on the correct recipe.

isn’t that automatic ? it informed me of the changing providers for shared libs, util-linux packaging is quite granular
and the move to libs is at output PACKAGES boundary, just the recipe provider is changing.

> 
> We end up with two separate do_install tasks which are fragile and that
> changes during version upgrades get handled correctly with changes being
> made to both functions equally and carefully. avahi has tended to break
> more readily than other recipes duing upgrades.

We could use common include. I did not bother in version 1 but it certainly is possible.

> 
> The PROVIDER namespaces must not overlap and MLPREFIX needs to be
> correctly injected into the correct places, particularly given the more
> hardcoded package names.
> 
> Now, I agree we can probably hand craft a recipe which works and doesn't
> have any problem above. Is it maintainable? Will issues come up in the
> future? Am I going to get 101 questions and complaints about it?
> 

While I agree its a bit of more work but its future safe. and the patch I mentioned above does not address
all concerns but it can be made to do so. The steps you describe are all valid but we have a better
case with util-linux than other examples you mentioned.

> I don't believe it is as easy as you think to take this forward long
> term, much a I wish it were otherwise...
> 
> Cheers,
> 
> Richard
> 
> 
> 

Re: [PATCH 1/2] util-linux: disable systemd

[Richard Purdie]

On Tue, 2015-02-24 at 16:00 -0800, Khem Raj wrote:
> On Tue, Feb 24, 2015 at 3:32 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> >
> > In history we have no good example of successfully splitting one piece
> > of source over multiple recipes, apart from perhaps gcc which we'd all
> > agree is horrible in a variety of ways. Any time we have attempted this,
> > we've tended to revert or have calls to revert (e.g. avahi).
> 
> I asked for specific problems/issues observed with split builds. I got
> no concrete examples, yes it has to be done carefully but then I dont
> think its something that can not be fixed destabilize the release so
> much. We are building it twice identically and just changing the
> packaging. In any case, sometimes we should try to tackle the issues
> out of milestone pressures too.

You're not building it twice identically, if you were doing that we
wouldn't have this problem. You're trying to split it into two separate
chunks and ensuing they are independent, yet they do inter-depend
correctly when needed too.

If this is just a packaging problem, we should just ship the extra
systemd unit parts as part of a separate recipe and then have the main
util-linux recipe RDEPEND on it.

Specific examples:

You need to ensure that the PACKAGES generated by both sides of the
split have consistent naming (maybe overriding and doing what debian
packaging would have done should the split not been there). The PACKAGES
need to be careful about the contents of default PN for example. There
have been issues cleanly separating things into two -dev packages and
exposing two similar but slightly differently named -dev packages for
the same piece of software.

You have to ensure that the appropriate recipes each register as the
correct shlibs providers and that things DEPENDing on the recipe now
depend on the correct recipe.

We end up with two separate do_install tasks which are fragile and that
changes during version upgrades get handled correctly with changes being
made to both functions equally and carefully. avahi has tended to break
more readily than other recipes duing upgrades.

The PROVIDER namespaces must not overlap and MLPREFIX needs to be
correctly injected into the correct places, particularly given the more
hardcoded package names.

Now, I agree we can probably hand craft a recipe which works and doesn't
have any problem above. Is it maintainable? Will issues come up in the
future? Am I going to get 101 questions and complaints about it?

I don't believe it is as easy as you think to take this forward long
term, much a I wish it were otherwise...

Cheers,

Richard

Re: [PATCH 1/2] util-linux: disable systemd

[Khem Raj]

On Tue, Feb 24, 2015 at 3:32 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
>
> In history we have no good example of successfully splitting one piece
> of source over multiple recipes, apart from perhaps gcc which we'd all
> agree is horrible in a variety of ways. Any time we have attempted this,
> we've tended to revert or have calls to revert (e.g. avahi).

I asked for specific problems/issues observed with split builds. I got
no concrete examples, yes it has to be done carefully but then I dont
think its something that can not be fixed destabilize the release so
much. We are building it twice identically and just changing the
packaging. In any case, sometimes we should try to tackle the issues
out of milestone pressures too.

Re: [PATCH 1/2] util-linux: disable systemd

[Richard Purdie]

On Tue, 2015-02-24 at 12:48 -0800, Khem Raj wrote:
> > On Feb 24, 2015, at 10:07 AM, Ross Burton <ross.burton@intel.com> wrote:
> > 
> > systemd has a build-dependency on util-linux for libmount, and util-linux has an
> > optional build dependency on systemd.
> > 
> > The features in util-linux that enabling systemd gives you are:
> > * lslogins can show recent journal entries from the user
> > * uuidd can use socket activation and has a service file
> > * fstrim has a service file
> > * logger can write journal entries
> > 
> > These are not worth the overhead of maintaining two util-linux recipes to
> > bootstrap the cycle, so disable systemd support in util-linux.
> 
> I feel we are going out of way here since now on systemd based systemd you have to undo this change
> partly via re-introducing service files in some fashion
> how about just building and packaging uuidd and fstrim separately ?
> 
> atleast it should be reported to util-linux maintainers.

I'm going to merge this patch and I want to clearly explain why.

With systemd it does seem to pay to be one something approximating the
latest version. I can't do that without doing something about
util-linux.

In history we have no good example of successfully splitting one piece
of source over multiple recipes, apart from perhaps gcc which we'd all
agree is horrible in a variety of ways. Any time we have attempted this,
we've tended to revert or have calls to revert (e.g. avahi).

We're at M3 cutoff and we need to make some decision. If I choose not to
take this, nothing will make 1.8. If I take this, there is the
possibility we can fix up systemd util-linux in some way if it proves to
be that critical.

So whilst I don't think this is perfect and I agree it needs discussion
with the util-linux/systemd folks, I think its perhaps the least worst
option available to me and there are ways we can likely improve things
if/as needed.

Cheers,

Richard

Re: [PATCH 1/2] util-linux: disable systemd

[Bernhard Reutner-Fischer]

On February 24, 2015 9:51:51 PM GMT+01:00, "Burton, Ross" <ross.burton@intel.com> wrote:
>On 24 February 2015 at 20:48, Khem Raj <raj.khem@gmail.com> wrote:
>
>> I feel we are going out of way here since now on systemd based
>systemd you
>> have to undo this change
>> partly via re-introducing service files in some fashion
>> how about just building and packaging uuidd and fstrim separately ?
>>
>
>Well the question is how popular is uuidd and fstrim?  I can totally


I think fstrim is very popular these days.

The busybox version of fstrim is about 800b with all the fancy stuff turned on, IIRC.

Thanks,

>see
>that installing the service files if systemd is enabled is the obvious
>half-way and upstream supporting this would be good but I've no idea if
>they'd accept this.
>
>We are *very* close to M3 cut-off and landing the new systemd depends
>on
>something fixing the circular dependency.  I believe this patch is the
>path
>with the least impact that can be fixed post-M3 to install service
>files
>where appropriate without causing a circular build dependency.
>
>Ross
>
>
>------------------------------------------------------------------------

Re: [PATCH 1/2] util-linux: disable systemd

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

On 24 February 2015 at 20:48, Khem Raj <raj.khem@gmail.com> wrote:

> I feel we are going out of way here since now on systemd based systemd you
> have to undo this change
> partly via re-introducing service files in some fashion
> how about just building and packaging uuidd and fstrim separately ?
>

Well the question is how popular is uuidd and fstrim?  I can totally see
that installing the service files if systemd is enabled is the obvious
half-way and upstream supporting this would be good but I've no idea if
they'd accept this.

We are *very* close to M3 cut-off and landing the new systemd depends on
something fixing the circular dependency.  I believe this patch is the path
with the least impact that can be fixed post-M3 to install service files
where appropriate without causing a circular build dependency.

Ross

[-- Attachment #2: Type: text/html, Size: 1349 bytes --]

Re: [PATCH 1/2] util-linux: disable systemd

[Khem Raj]

> On Feb 24, 2015, at 10:07 AM, Ross Burton <ross.burton@intel.com> wrote:
> 
> systemd has a build-dependency on util-linux for libmount, and util-linux has an
> optional build dependency on systemd.
> 
> The features in util-linux that enabling systemd gives you are:
> * lslogins can show recent journal entries from the user
> * uuidd can use socket activation and has a service file
> * fstrim has a service file
> * logger can write journal entries
> 
> These are not worth the overhead of maintaining two util-linux recipes to
> bootstrap the cycle, so disable systemd support in util-linux.

I feel we are going out of way here since now on systemd based systemd you have to undo this change
partly via re-introducing service files in some fashion
how about just building and packaging uuidd and fstrim separately ?

atleast it should be reported to util-linux maintainers.

> 
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
> meta/recipes-core/util-linux/util-linux.inc |    5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
> index b4f51e9..3d8a4d0 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -48,8 +48,7 @@ SHARED_EXTRA_OECONF = "--disable-use-tty-group \
> 
> EXTRA_OECONF = "${SHARED_EXTRA_OECONF} --libdir=${base_libdir}"
> 
> -PACKAGECONFIG_class-target ?= "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '', d)} \
> -                                ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} "
> +PACKAGECONFIG_class-target ?= "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '', d)}"
> PACKAGECONFIG[pam] = "--enable-su --enable-runuser,--disable-su --disable-runuser, libpam,"
> 
> # Respect the systemd feature for uuidd
> @@ -117,7 +116,7 @@ RDEPENDS_${PN}_class-nativesdk = ""
> 
> RPROVIDES_${PN}-dev = "util-linux-libblkid-dev util-linux-libmount-dev util-linux-libuuid-dev"
> 
> -SYSTEMD_PACKAGES = "${PN}-uuidd ${PN}-fstrim"
> +#SYSTEMD_PACKAGES = "${PN}-uuidd ${PN}-fstrim"
> SYSTEMD_SERVICE_${PN}-uuidd = "uuidd.socket uuidd.service"
> SYSTEMD_AUTO_ENABLE_${PN}-uuidd = "disable"
> SYSTEMD_SERVICE_${PN}-fstrim = "fstrim.timer fstrim.service"
> -- 
> 1.7.10.4
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

[PATCH 1/2] util-linux: disable systemd

[Ross Burton]

systemd has a build-dependency on util-linux for libmount, and util-linux has an
optional build dependency on systemd.

The features in util-linux that enabling systemd gives you are:
* lslogins can show recent journal entries from the user
* uuidd can use socket activation and has a service file
* fstrim has a service file
* logger can write journal entries

These are not worth the overhead of maintaining two util-linux recipes to
bootstrap the cycle, so disable systemd support in util-linux.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-core/util-linux/util-linux.inc |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc b/meta/recipes-core/util-linux/util-linux.inc
index b4f51e9..3d8a4d0 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -48,8 +48,7 @@ SHARED_EXTRA_OECONF = "--disable-use-tty-group \
 
 EXTRA_OECONF = "${SHARED_EXTRA_OECONF} --libdir=${base_libdir}"
 
-PACKAGECONFIG_class-target ?= "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '', d)} \
-                                ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} "
+PACKAGECONFIG_class-target ?= "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam', '', d)}"
 PACKAGECONFIG[pam] = "--enable-su --enable-runuser,--disable-su --disable-runuser, libpam,"
 
 # Respect the systemd feature for uuidd
@@ -117,7 +116,7 @@ RDEPENDS_${PN}_class-nativesdk = ""
 
 RPROVIDES_${PN}-dev = "util-linux-libblkid-dev util-linux-libmount-dev util-linux-libuuid-dev"
 
-SYSTEMD_PACKAGES = "${PN}-uuidd ${PN}-fstrim"
+#SYSTEMD_PACKAGES = "${PN}-uuidd ${PN}-fstrim"
 SYSTEMD_SERVICE_${PN}-uuidd = "uuidd.socket uuidd.service"
 SYSTEMD_AUTO_ENABLE_${PN}-uuidd = "disable"
 SYSTEMD_SERVICE_${PN}-fstrim = "fstrim.timer fstrim.service"
-- 
1.7.10.4