Re: [gentoo-dev] Re: [PATCH] profiles: Enable USE=user-session on systemd profiles

[Mike Gilbert]

On Sat, Mar 21, 2020 at 6:43 AM Mart Raudsepp <leio@g.o> wrote:
>
> Ühel kenal päeval, L, 21.03.2020 kell 11:16, kirjutas Pacho Ramos:
> > I agree, I see that also Debian is applying it unconditionally even
> > when running
> > systemd
>
> But I assume it would be a problem with USE=systemd + USE=-user-session
> dbus, so how about instead of this profile business, we then just go
> with:
>
> * Revbump bluez to drop IUSE=user-session, unconditionally apply the
> patch and change the dbus dep in systemd conditional to
> >=sys-apps/dbus-1.6:=[user-session(+)]
> * Fix bluez USE=systemd handling in above revbump as well: --enable-
> systemd should always be passed, not controlled by a USE=systemd,
> because all it appears to do is decide whether to install systemd
> service files, and that should be always done per the small files
> policy.
>
> * Revbump dbus, dropping user-session IUSE and unconditionally passing
> --enable-user-session

I think we should probably move it behind USE=systemd. It should
probably be that way already, but I missed it when adding the
user-session flag to the dbus ebuild.

There is a quite a bit of conditionally compiled code in dbus-daemon
that gets disabled if --disable-systemd is passed to configure. I
would guess that dbus.service will not function properly if this code
is not enabled.

Since we are dropping user-session from IUSE, the following should suffice:

$(use_enable systemd user-session)

> * After some time (dbus revision with IUSE=user-session has been gone
> for a while), remove all of the IUSE=systemd handling from bluez, as
> the user-session matching enforcement isn't needed anymore (and the
> configure systemd conditional has been nuked per above)
> * At that point the package.use entries can be removed altogether as
> well, instead of migrating to systemd target profile.

Agreed on the rest of the plan.