[gentoo-dev] Making systemd more accessible to "normal" users

[Fabio Erculiani]

PLEASE DO NOT START A FLAME WAR AND READ ON FIRST.
THIS IS NOT A POST AGAINST OPENRC.

With the release of Sabayon 13.04 [1] and thanks to the efforts I put
into the systemd-love overlay [2], systemd has become much more
accessible and easy to migrate to/from openrc. Both are able to
happily coexist and logind/consolekit detection is now done at
runtime.
It is sad to say that the "territoriality" in base-system (and
toolchain) is not allowing any kind of progress [3] [4]. This is
nothing new, by the way.

There are several components that need patching in order to work as
expected with systemd:
- polkit needs a patch that enables runtime detection of logind/consolekit
- pambase needs to drop USE=systemd and always enable the optional
module pam_systemd.so
- genkernel needs to migrate to *udev (or as I did, provide a --udev
genkernel option), mdev is unable to properly activate LVM volumes and
LVM is actually working by miracle with openrc. Alternatively, we
should migrate to dracut.
- networkmanager need not to install/remove files depending on
USE=systemd but rather detect systemd at runtime, which is a 3 lines
script.
- openrc-settingsd needs to support eselect-settingsd, which makes
possible to switch the settingsd implementation at runtime, between
openrc and systemd. This also removes the silly conflict between
openrc-settingsd and systemd friends.
- genkernel should at least support plymouth (work in progress my side)
- other ~490 systemd units are missing at this time and writing them
could also be a great GSoC project (don't look at me, I'm busy
enough).

All this would come with no cost for the current openrc state
(actually, my initramfs speed improvements patches in genkernel.git
also benefit openrc).
If Gentoo is about choice, we should give our users the right to
choose between the init system they like the most.

It looks like there is some consensus on the effort of making systemd
more accessible, while there are problems with submitting bugs about
new systemd units of the sort that maintainers just_dont_answer(tm).
In this case, I am just giving 3 weeks grace period for maintainers to
answer and then I usually go ahead adding units (I'm in systemd@ after
all).

The only remaining problem is about eselect-sysvinit, for this reason,
I am probably going to create a new separate pkg called
_sysvinit-next_, that contains all the fun stuff many developers were
not allowed to commit (besides my needs, there is also the need of
splitting sysvinit due to the issues reported in [4]). I am sure that
a masked alternative sysvinit ebuild won't hurt anybody and will make
Gentoo a bit more fun to use.

The final outcome will hopefully be:
- easier to migrate from/to systemd, at runtime, with NO recompilation
at all (just enable USE=systemd and switch the device manager from
*udev to systemd -- unless somebody wants to drop the udev part from
systemd, if at all possible)
- we give the users the right to choose without driving them nuts with
weird emerge-fu.
- we make possible to support new init systems in future, and even
specific init wrappers (bootchart anyone?)
- we prepare the path towards a painless migration from consolekit
(deprecated for long time now) to logind (we probably need to fork it
off the systemd pkg -- upstream projects are _dropping_ consolekit
support right now!)
- we put back some fun into Gentoo

If you want to see a working implementation of my systemd-love
efforts, just go download [1] and see things working yourself.

[1] http://www.sabayon.org/release/press-release-sabayon-1304
[2] https://github.com/Sabayon/systemd-love
[3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236
[4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615

Cheers,
--
Fabio Erculiani

[Pacho Ramos]

El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió:
[...]

> - other ~490 systemd units are missing at this time and writing them
> could also be a great GSoC project (don't look at me, I'm busy
> enough).

[...]

Can't them be stolen from other distros running systemd?

[...]

> The only remaining problem is about eselect-sysvinit, for this reason,
> I am probably going to create a new separate pkg called
> _sysvinit-next_, that contains all the fun stuff many developers were
> not allowed to commit (besides my needs, there is also the need of
> splitting sysvinit due to the issues reported in [4]). I am sure that
> a masked alternative sysvinit ebuild won't hurt anybody and will make
> Gentoo a bit more fun to use.
>

I am unable to find exact advantage of changing init system without
rebooting :/, what is the advantage of booting with an init.d and
shutting down with a different one?

> The final outcome will hopefully be:
> - easier to migrate from/to systemd, at runtime, with NO recompilation
> at all (just enable USE=systemd and switch the device manager from
> *udev to systemd -- unless somebody wants to drop the udev part from
> systemd, if at all possible)

Are udev and systemd-udev-part really equivalent? I mean, since they are
maintained by different people downstream, I am not sure if there would
be differences in how udev from udev ebuild and udev from systemd ebuild
will behave.

Best regards and thanks for your work!

[Fabio Erculiani]

On Wed, May 1, 2013 at 12:50 PM, Pacho Ramos <pa...@gentoo.org> wrote:
> El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió:
> [...]
>> - other ~490 systemd units are missing at this time and writing them
>> could also be a great GSoC project (don't look at me, I'm busy
>> enough).
> [...]
>
> Can't them be stolen from other distros running systemd?

Sure, Arch and Fedora repositories are a good source.

>
> [...]
>> The only remaining problem is about eselect-sysvinit, for this reason,
>> I am probably going to create a new separate pkg called
>> _sysvinit-next_, that contains all the fun stuff many developers were
>> not allowed to commit (besides my needs, there is also the need of
>> splitting sysvinit due to the issues reported in [4]). I am sure that
>> a masked alternative sysvinit ebuild won't hurt anybody and will make
>> Gentoo a bit more fun to use.
>>
>
> I am unable to find exact advantage of changing init system without
> rebooting :/, what is the advantage of booting with an init.d and
> shutting down with a different one?

No, you don't boot with A and shutdown with B. B is loaded by the
kernel at the next boot.
Switching init system is the only way to roll out a migration path,
among other things I already wrote about on the eselect-sysvinit bug.

>
>> The final outcome will hopefully be:
>> - easier to migrate from/to systemd, at runtime, with NO recompilation
>> at all (just enable USE=systemd and switch the device manager from
>> *udev to systemd -- unless somebody wants to drop the udev part from
>> systemd, if at all possible)
>
> Are udev and systemd-udev-part really equivalent? I mean, since they are
> maintained by different people downstream, I am not sure if there would
> be differences in how udev from udev ebuild and udev from systemd ebuild
> will behave.

This needs investigation.

>
> Best regards and thanks for your work!
>
>

--
Fabio Erculiani

[Pacho Ramos]

El mié, 01-05-2013 a las 13:00 +0200, Fabio Erculiani escribió:
[...]

> >> The only remaining problem is about eselect-sysvinit, for this reason,
> >> I am probably going to create a new separate pkg called
> >> _sysvinit-next_, that contains all the fun stuff many developers were
> >> not allowed to commit (besides my needs, there is also the need of
> >> splitting sysvinit due to the issues reported in [4]). I am sure that
> >> a masked alternative sysvinit ebuild won't hurt anybody and will make
> >> Gentoo a bit more fun to use.
> >>
> >
> > I am unable to find exact advantage of changing init system without
> > rebooting :/, what is the advantage of booting with an init.d and
> > shutting down with a different one?
>
> No, you don't boot with A and shutdown with B. B is loaded by the
> kernel at the next boot.
> Switching init system is the only way to roll out a migration path,
> among other things I already wrote about on the eselect-sysvinit bug.
>

Ah! OK, I misunderstood the "runtime" sense, in that case looks
interesting :D

[Steven J. Long]

On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote:
> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST.
> THIS IS NOT A POST AGAINST OPENRC.
>
> With the release of Sabayon 13.04 [1] and thanks to the efforts I put
> into the systemd-love overlay [2], systemd has become much more
> accessible and easy to migrate to/from openrc. Both are able to
> happily coexist and logind/consolekit detection is now done at
> runtime.

That's great: well done :-)

Can I just check: what about people not using consolekit nor logind?

> It is sad to say that the "territoriality" in base-system (and
> toolchain) is not allowing any kind of progress [3] [4]. This is
> nothing new, by the way.

I don't think you help yourself by making that kind of remark: when I read
those bugs I see some valid concerns being raised, which you just ignore.
For instance, wrt "nonsensical blockers" I too would like to know some
examples, as was queried in comment 27 [3]. In fact it was the first thing
that came to mind when reading your post, as I thought where possible things
were just installed for systemd (such as unit files) even when the user
is not using it.

> There are several components that need patching in order to work as
> expected with systemd:
> - polkit needs a patch that enables runtime detection of logind/consolekit
> - pambase needs to drop USE=systemd and always enable the optional
> module pam_systemd.so

Again, what about people not using consolekit, nor logind, with no intention
of ever installing systemd? I've got nothing against this so long as it
is guaranteed not to break my pam setup. As-is I feel *very* wary of a change
that unconditionally requires a 'pam_systemd.so'. Please note I am not hostile
to your aims: I am merely seeking reassurance.

> - genkernel needs to migrate to *udev (or as I did, provide a --udev
> genkernel option), mdev is unable to properly activate LVM volumes and
> LVM is actually working by miracle with openrc.

Why is that such a "miracle"? openrc has worked with lvm since the beginning
afair, and is both clean, portable C, and modular.

> Alternatively, we should migrate to dracut.
> - networkmanager need not to install/remove files depending on
> USE=systemd but rather detect systemd at runtime, which is a 3 lines
> script.

Sounds reasonable; since I don't use it, that can't affect me in any case.

> - openrc-settingsd needs to support eselect-settingsd, which makes
> possible to switch the settingsd implementation at runtime, between
> openrc and systemd. This also removes the silly conflict between
> openrc-settingsd and systemd friends.
> - genkernel should at least support plymouth (work in progress my side)
> - other ~490 systemd units are missing at this time and writing them
> could also be a great GSoC project (don't look at me, I'm busy
> enough).
>
> All this would come with no cost for the current openrc state
> (actually, my initramfs speed improvements patches in genkernel.git
> also benefit openrc).
> If Gentoo is about choice, we should give our users the right to
> choose between the init system they like the most.

I must be missing something as I thought they already had that choice.

From reading the bug, the only pro of your approach is that the user
does not have to edit the kernel command-line to try out a new init.
Initially, you tried to sell this as "lowering the bar" which is actually
a con afaic: if someone is trying to run Gentoo and is incapable of
dealing with the kernel command-line, it's likely they won't be able to
install it; they certainly won't be able to maintain it, ime.

Later, we get the "some EFI bootloaders don't allow it." Could you elaborate
on how a system we install grub to, won't allow us to change anything?
I am not doubting you: I just think we need more explanation of the exact
context where we can install Gentoo, but not a bootloader.

> It looks like there is some consensus on the effort of making systemd
> more accessible,

Sure there is: there's also consensus that this approach is wrong for
Gentoo. And I have to concur, without further reasoning from you. Switching
init isn't done that often, and when it is a Gentoo user is expected to
deal with configuration. In this case, it's a doddle to set the command-line
to init=/sbin/fubar to try it, and then when it's running the user can
change the symlink, or just revert as they choose.

If they can't handle the above, they shouldn't be on Gentoo imo. And sabayon
already sets up systemd, so I don't see the use-case frankly. Apart from making
Gentoo base-system more suitable for direct usage in Sabayon, which is not our
problem.

What are the effects for other downstreams? Funtoo for instance, has been
swimming against the upstream udev/systemd mania, from glancing at their site
recently. Have you consulted with other downstreams about their needs and got
buy-in from them too? That would strengthen your case, tho imo it's weak
irrespective of what systemd-preferring downstreams want: after all, they're
distros, not Gentoo users, and are supposed to be expert at setting things up.

So I just don't see which Gentoo users this is helping. Making it even more
trivial to change init than it already is, is actually a bad thing in my eyes.
It gives the impression that it can be undertaken lightly which is simply bad
practice.

> while there are problems with submitting bugs about
> new systemd units of the sort that maintainers just_dont_answer(tm).
> In this case, I am just giving 3 weeks grace period for maintainers to
> answer and then I usually go ahead adding units (I'm in systemd@ after
> all).

AFAIK it's been policy for a while that systemd unit files should be installed
by default, for all the reasons you've given. I can't see a maintainer being
bothered by the systemd herd adding them when they have no interest: after all
users can already set an INSTALL_MASK, and it makes binpkgs more useful.

> The only remaining problem is about eselect-sysvinit, for this reason,
> I am probably going to create a new separate pkg called
> _sysvinit-next_, that contains all the fun stuff many developers were
> not allowed to commit (besides my needs, there is also the need of
> splitting sysvinit due to the issues reported in [4]). I am sure that
> a masked alternative sysvinit ebuild won't hurt anybody and will make
> Gentoo a bit more fun to use.
>
> The final outcome will hopefully be:
> - easier to migrate from/to systemd, at runtime, with NO recompilation
> at all (just enable USE=systemd and switch the device manager from
> *udev to systemd -- unless somebody wants to drop the udev part from
> systemd, if at all possible)

How is adding USE=systemd to a system with it switched off (ie: enabling it),
*not* going to lead to recompilation?

> - we give the users the right to choose without driving them nuts with
> weird emerge-fu.

What weird "emerge-fu"? You haven't outlined any at all. Unless you mean
changing a USE flag and the standard emerge process, which isn't what anyone
here would think of as "emerge-fu": just normal usage.

Also, if you can't handle emerge, you really should be on another distro.

> - we make possible to support new init systems in future, and even
> specific init wrappers (bootchart anyone?)

Which is possible already, so this is null.

> - we prepare the path towards a painless migration from consolekit
> (deprecated for long time now) to logind (we probably need to fork it
> off the systemd pkg -- upstream projects are _dropping_ consolekit
> support right now!)

Some people don't use either. For good reason, but let's not get into a
flamewar: let's leave it as that "choice" thing you mentioned before. I
take it those users will not see any breakage beyond missing "features"?

> - we put back some fun into Gentoo

Eh, I've been having much more fun since I got rid of semantic-craptop,
switched to mutt[A], and turned off all nubkit-related flags. My KDE came
back to me, and runs smooth just like 3.5 used to :) Then I replaced my
/bin/sh with /bin/bb which sped up bootup by an order of perceived
magnitude, and also sped up the _rest_ of my system. Of course, the latter
is only possible because Unix is designed on a modular basis, and we can
still swap components in and out on Linux (for now.)

> If you want to see a working implementation of my systemd-love
> efforts, just go download [1] and see things working yourself.
>
> [1] http://www.sabayon.org/release/press-release-sabayon-1304
> [2] https://github.com/Sabayon/systemd-love
> [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236
> [4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615

Again, I don't think you help your case with this remark. I expected the
"useless crap" to be a reference to lennart-ware. In fact, he was pointing
out that he told you all 8 months ago to raise it upstream: several commands
had already been migrated in upstream git according to another comment. So
the "useless crap" was in fact what he'd usually call whining ime, about the
lack of a "magic fix."

Please note: I fully support your effort to make it easy to switch back
and forth (I actually believe many people who try out openrc will stay with it.)
I just don't think that adding a fragile eselect module (along with "this needs
investigation" as things come up) is the way to do it. Nor does it solve
any real problem in the Gentoo context. Nor should someone change init on a whim,
without being ready to handle configuration.

In fact, dumbing down Gentoo is dangerous imo. It makes it far more likely
that user will mess up something else more significant, likely leading to data
loss. Gentoo, like Unix, doesn't stop you from doing stupid things, as that
would stop you doing clever things. If you're not ready for that (which the
install process beats into you) then you're better off not using it, afaic.

That last is actually the reason I haven't put our installer out to users on
the forum: I don't think it's a good idea to have an automated install unless
you've done at least 2 manual ones. And that would go out the window with
an easy installer. Perhaps that's why you feel Sabayon users need the Gentoo
bar lowered.

To my mind the answer to that is to educate them some more, and make it clear
that Gentoo is not Sabayon for that very reason. It's not meant to hold your
hand: it's far more likely to slap you on the wrist. Or indeed shoot your foot
off if, and only if, you tell it to.

Regards,
steveL.

[A] "kmail to mutt with maildir and procmail"
http://forums.gentoo.org/viewtopic-t-945868.html

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[Michał Górny]

On Wed, 01 May 2013 12:50:42 +0200
Pacho Ramos <pa...@gentoo.org> wrote:

> El mié, 01-05-2013 a las 12:04 +0200, Fabio Erculiani escribió:
> [...]
> > - other ~490 systemd units are missing at this time and writing them
> > could also be a great GSoC project (don't look at me, I'm busy
> > enough).
> [...]
>
> Can't them be stolen from other distros running systemd?

Yes and no. Fedora took the quick way of switching to systemd which
means some of the units are really poor quality. For example, they rely
on configs in /etc/sysconfig which we don't want to port to Gentoo.

I'd prefer if someone took the task really serious and worked hard to
get:

a) fixed config handling in upstream packages (thus allowing for better
unit files),

b) really good unit files,

c) bugs for upstreams to try to include those good files or fix
the existing ones.

> [...]

> > The final outcome will hopefully be:
> > - easier to migrate from/to systemd, at runtime, with NO recompilation
> > at all (just enable USE=systemd and switch the device manager from
> > *udev to systemd -- unless somebody wants to drop the udev part from
> > systemd, if at all possible)
>
> Are udev and systemd-udev-part really equivalent? I mean, since they are
> maintained by different people downstream, I am not sure if there would
> be differences in how udev from udev ebuild and udev from systemd ebuild
> will behave.

There may be differences. For example, I'm not really interested
in patching systemd with patches from eudev which will never make it
upstream. Therefore, systemd-udevd won't work with old kernels systemd
does not support.

--
Best regards,
Michał Górny

[Fabio Erculiani]

On Wed, May 1, 2013 at 2:54 PM, Steven J. Long
<sl...@rathaus.eclipse.co.uk> wrote:
> On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote:
>> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST.
>> THIS IS NOT A POST AGAINST OPENRC.
>>
>> With the release of Sabayon 13.04 [1] and thanks to the efforts I put
>> into the systemd-love overlay [2], systemd has become much more
>> accessible and easy to migrate to/from openrc. Both are able to
>> happily coexist and logind/consolekit detection is now done at
>> runtime.
>
> That's great: well done :-)
>
> Can I just check: what about people not using consolekit nor logind?

This has nothing to do with it. If you don't want consolekit nor
logind just USE="-consolekit -systemd".
It looks like you haven't clear what I'm writing about, though.

>
>> It is sad to say that the "territoriality" in base-system (and
>> toolchain) is not allowing any kind of progress [3] [4]. This is
>> nothing new, by the way.
>
> I don't think you help yourself by making that kind of remark: when I read
> those bugs I see some valid concerns being raised, which you just ignore.
> For instance, wrt "nonsensical blockers" I too would like to know some
> examples, as was queried in comment 27 [3]. In fact it was the first thing
> that came to mind when reading your post, as I thought where possible things
> were just installed for systemd (such as unit files) even when the user
> is not using it.

Have you ever tried to fully migrate to systemd from openrc? Clearly not.

>
> > There are several components that need patching in order to work as
>> expected with systemd:
>> - polkit needs a patch that enables runtime detection of logind/consolekit
>> - pambase needs to drop USE=systemd and always enable the optional
>> module pam_systemd.so
>
> Again, what about people not using consolekit, nor logind, with no intention
> of ever installing systemd? I've got nothing against this so long as it
> is guaranteed not to break my pam setup. As-is I feel *very* wary of a change
> that unconditionally requires a 'pam_systemd.so'. Please note I am not hostile
> to your aims: I am merely seeking reassurance.

Do you know how pam works? And did you understand the meaning of my
words? Do you know what optional means in this context?

>
>> - genkernel needs to migrate to *udev (or as I did, provide a --udev
>> genkernel option), mdev is unable to properly activate LVM volumes and
>> LVM is actually working by miracle with openrc.
>
> Why is that such a "miracle"? openrc has worked with lvm since the beginning
> afair, and is both clean, portable C, and modular.

Do you know how LVM and udev and systemd interact wrt volumes activation?

>
>> Alternatively, we should migrate to dracut.
>> - networkmanager need not to install/remove files depending on
>> USE=systemd but rather detect systemd at runtime, which is a 3 lines
>> script.
>
> Sounds reasonable; since I don't use it, that can't affect me in any case.

My goal wrt openrc is to keep the current level of support and just
make systemd users' life easier.

>
>> - openrc-settingsd needs to support eselect-settingsd, which makes
>> possible to switch the settingsd implementation at runtime, between
>> openrc and systemd. This also removes the silly conflict between
>> openrc-settingsd and systemd friends.
>> - genkernel should at least support plymouth (work in progress my side)
>> - other ~490 systemd units are missing at this time and writing them
>> could also be a great GSoC project (don't look at me, I'm busy
>> enough).
>>
>> All this would come with no cost for the current openrc state
>> (actually, my initramfs speed improvements patches in genkernel.git
>> also benefit openrc).
>> If Gentoo is about choice, we should give our users the right to
>> choose between the init system they like the most.
>
> I must be missing something as I thought they already had that choice.

Please, write about something you actually manage to _know_. And also,
please do read my post title.
This is not a flamewar topic, I want to discuss about improving the
systemd experience.

>
> From reading the bug, the only pro of your approach is that the user
> does not have to edit the kernel command-line to try out a new init.
> Initially, you tried to sell this as "lowering the bar" which is actually
> a con afaic: if someone is trying to run Gentoo and is incapable of
> dealing with the kernel command-line, it's likely they won't be able to
> install it; they certainly won't be able to maintain it, ime.
>
> Later, we get the "some EFI bootloaders don't allow it." Could you elaborate
> on how a system we install grub to, won't allow us to change anything?
> I am not doubting you: I just think we need more explanation of the exact
> context where we can install Gentoo, but not a bootloader.

Being Gentoo does not absolutely mean that we have to craft watches
and play VHS with the tongue every time we want to do something.
Making things easy is an orthogonal concept!

>
>> It looks like there is some consensus on the effort of making systemd
>> more accessible,
>
> Sure there is: there's also consensus that this approach is wrong for
> Gentoo. And I have to concur, without further reasoning from you. Switching
> init isn't done that often, and when it is a Gentoo user is expected to
> deal with configuration. In this case, it's a doddle to set the command-line
> to init=/sbin/fubar to try it, and then when it's running the user can
> change the symlink, or just revert as they choose.
>
> If they can't handle the above, they shouldn't be on Gentoo imo. And sabayon
> already sets up systemd, so I don't see the use-case frankly. Apart from making
> Gentoo base-system more suitable for direct usage in Sabayon, which is not our
> problem.

That's not absolutely the point, I am sorry. The topic here is to
improve the systemd experience, if you are an openrc user that doesn't
care about systemd and other stuff, you are off topic.

>
> What are the effects for other downstreams? Funtoo for instance, has been
> swimming against the upstream udev/systemd mania, from glancing at their site
> recently. Have you consulted with other downstreams about their needs and got
> buy-in from them too? That would strengthen your case, tho imo it's weak
> irrespective of what systemd-preferring downstreams want: after all, they're
> distros, not Gentoo users, and are supposed to be expert at setting things up.
>
> So I just don't see which Gentoo users this is helping. Making it even more
> trivial to change init than it already is, is actually a bad thing in my eyes.
> It gives the impression that it can be undertaken lightly which is simply bad
> practice.

We should stop thinking about Gentoo like a guru-distro. Gentoo is
about choice, but choice != complexity. Making things easier is not
against our Manifesto.
Gentoo is about choice, which to me also means "embrace diversitiy".
If you want to keep living in your little world, fine, you can and
you're very welcome, but also people who want to have fun with new
stuff should get the same respect. Implementing new stuff also means
making things easier, especially in the systemd case.

>
>> while there are problems with submitting bugs about
>> new systemd units of the sort that maintainers just_dont_answer(tm).
>> In this case, I am just giving 3 weeks grace period for maintainers to
>> answer and then I usually go ahead adding units (I'm in systemd@ after
>> all).
>
> AFAIK it's been policy for a while that systemd unit files should be installed
> by default, for all the reasons you've given. I can't see a maintainer being
> bothered by the systemd herd adding them when they have no interest: after all
> users can already set an INSTALL_MASK, and it makes binpkgs more useful.
>

Thanks for reminding me a policy I am supposed to already know about.

>> The only remaining problem is about eselect-sysvinit, for this reason,
>> I am probably going to create a new separate pkg called
>> _sysvinit-next_, that contains all the fun stuff many developers were
>> not allowed to commit (besides my needs, there is also the need of
>> splitting sysvinit due to the issues reported in [4]). I am sure that
>> a masked alternative sysvinit ebuild won't hurt anybody and will make
>> Gentoo a bit more fun to use.
>>
>> The final outcome will hopefully be:
>> - easier to migrate from/to systemd, at runtime, with NO recompilation
>> at all (just enable USE=systemd and switch the device manager from
>> *udev to systemd -- unless somebody wants to drop the udev part from
>> systemd, if at all possible)
>
> How is adding USE=systemd to a system with it switched off (ie: enabling it),
> *not* going to lead to recompilation?
>

Because you enable it once and for all and still have a _WORKING_ openrc.
Please take more time reading about what's in my overlay before jumping the gun.

>> - we give the users the right to choose without driving them nuts with
>> weird emerge-fu.
>
> What weird "emerge-fu"? You haven't outlined any at all. Unless you mean
> changing a USE flag and the standard emerge process, which isn't what anyone
> here would think of as "emerge-fu": just normal usage.
>
> Also, if you can't handle emerge, you really should be on another distro.
>

Same as above. You're talking about something you haven't even managed
to try. I'm sorry to tell you.

>> - we make possible to support new init systems in future, and even
>> specific init wrappers (bootchart anyone?)
>
> Which is possible already, so this is null.

It is not.

>
>> - we prepare the path towards a painless migration from consolekit
>> (deprecated for long time now) to logind (we probably need to fork it
>> off the systemd pkg -- upstream projects are _dropping_ consolekit
>> support right now!)
>
> Some people don't use either. For good reason, but let's not get into a
> flamewar: let's leave it as that "choice" thing you mentioned before. I
> take it those users will not see any breakage beyond missing "features"?

This doesn't affect such users.

>
>> - we put back some fun into Gentoo
>
> Eh, I've been having much more fun since I got rid of semantic-craptop,
> switched to mutt[A], and turned off all nubkit-related flags. My KDE came
> back to me, and runs smooth just like 3.5 used to :) Then I replaced my
> /bin/sh with /bin/bb which sped up bootup by an order of perceived
> magnitude, and also sped up the _rest_ of my system. Of course, the latter
> is only possible because Unix is designed on a modular basis, and we can
> still swap components in and out on Linux (for now.)

You're not the user I'm trying to work for. But yet nothing would
change for you.

>
>> If you want to see a working implementation of my systemd-love
>> efforts, just go download [1] and see things working yourself.
>>
>> [1] http://www.sabayon.org/release/press-release-sabayon-1304
>> [2] https://github.com/Sabayon/systemd-love
>> [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236
>> [4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615
>
> Again, I don't think you help your case with this remark. I expected the
> "useless crap" to be a reference to lennart-ware. In fact, he was pointing
> out that he told you all 8 months ago to raise it upstream: several commands
> had already been migrated in upstream git according to another comment. So
> the "useless crap" was in fact what he'd usually call whining ime, about the
> lack of a "magic fix."

Please join Gentoo first.

>
> Please note: I fully support your effort to make it easy to switch back
> and forth (I actually believe many people who try out openrc will stay with it.)
> I just don't think that adding a fragile eselect module (along with "this needs
> investigation" as things come up) is the way to do it. Nor does it solve
> any real problem in the Gentoo context. Nor should someone change init on a whim,
> without being ready to handle configuration.
>
> In fact, dumbing down Gentoo is dangerous imo. It makes it far more likely
> that user will mess up something else more significant, likely leading to data
> loss. Gentoo, like Unix, doesn't stop you from doing stupid things, as that
> would stop you doing clever things. If you're not ready for that (which the
> install process beats into you) then you're better off not using it, afaic.
>
> That last is actually the reason I haven't put our installer out to users on
> the forum: I don't think it's a good idea to have an automated install unless
> you've done at least 2 manual ones. And that would go out the window with
> an easy installer. Perhaps that's why you feel Sabayon users need the Gentoo
> bar lowered.
>
> To my mind the answer to that is to educate them some more, and make it clear
> that Gentoo is not Sabayon for that very reason. It's not meant to hold your
> hand: it's far more likely to slap you on the wrist. Or indeed shoot your foot
> off if, and only if, you tell it to.

Thanks for your feedback.

>
> Regards,
> steveL.
>
> [A] "kmail to mutt with maildir and procmail"
> http://forums.gentoo.org/viewtopic-t-945868.html
>
> --
> #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
>

--
Fabio Erculiani

[Matthew Thode]

Isn't there a tracker (and if not, why have you not created one yet :P )

--
-- Matthew Thode (prometheanfire)

[Fabio Erculiani]

There is no tracker yet. But it may be very well materialize at some point.

--
Fabio Erculiani

[Rich Freeman]

On Wed, May 1, 2013 at 6:04 AM, Fabio Erculiani <lx...@gentoo.org> wrote:
> - genkernel needs to migrate to *udev (or as I did, provide a --udev
> genkernel option), mdev is unable to properly activate LVM volumes and
> LVM is actually working by miracle with openrc. Alternatively, we
> should migrate to dracut.

I'm not sure what "migrating to dracut" actually means. A gentoo
install doesn't include genkernel in the first place - it is installed
manually.

If you mean documenting how to use dracut in the handbook, then I
think that makes sense - we already document multiple alternatives
like genkernel, manual kernel builds, grub, lilo, etc.

I've been running dracut for almost a year now and it has been working
well, though I might note that I had to build a custom module to get
mdadm+LVM to work (not sure if current versions work out of the box,
and my use of old mdadm metadata versions due to previously having
followed the Gentoo mdadm+lvm guide might have something to do with
it).

Honestly, I'm not sure how important it is to be able to switch
back/forth at runtime. We should definitely support both options
reasonably well, but not to the point where people end up with a lot
of dependencies/complexity that a typical user doesn't actually have
need for.

Rich

[Steven J. Long]

On Wed, May 01, 2013 at 03:14:07PM +0100, Fabio Erculiani wrote:
> On Wed, May 1, 2013 at 2:54 PM, Steven J. Long
> <sl...@rathaus.eclipse.co.uk> wrote:
> > On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote:
> >> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST.
> >> THIS IS NOT A POST AGAINST OPENRC.
> >>
> >> With the release of Sabayon 13.04 [1] and thanks to the efforts I put
> >> into the systemd-love overlay [2], systemd has become much more
> >> accessible and easy to migrate to/from openrc. Both are able to
> >> happily coexist and logind/consolekit detection is now done at
> >> runtime.
> >
> > That's great: well done :-)
> >
> > Can I just check: what about people not using consolekit nor logind?
>
> This has nothing to do with it. If you don't want consolekit nor
> logind just USE="-consolekit -systemd".
> It looks like you haven't clear what I'm writing about, though.

Ah I see: sorry you're taking my email in the wrong spirit. I thought I made
it quite clear I'm not hostile to your intentions, but you appear to be hostile
to everything I've written.

FTR, as I said I was "just checking" that there would not be a hard dependency
introduced, since a) it would affect me and b) I wanted to know you're aware of
those use-cases, and that you already keep them in mind, going forward.

When someone says "just checking" or "can I just check.." it means they don't
expect there's any issue, but they'd like to be sure. Hence "just" a "check".

> >> It is sad to say that the "territoriality" in base-system (and
> >> toolchain) is not allowing any kind of progress [3] [4]. This is
> >> nothing new, by the way.
> >
> > I don't think you help yourself by making that kind of remark: when I read
> > those bugs I see some valid concerns being raised, which you just ignore.
> > For instance, wrt "nonsensical blockers" I too would like to know some
> > examples, as was queried in comment 27 [3]. In fact it was the first thing
> > that came to mind when reading your post, as I thought where possible things
> > were just installed for systemd (such as unit files) even when the user
> > is not using it.
>
> Have you ever tried to fully migrate to systemd from openrc? Clearly not.

OFC not, that's the point: it's why I'm asking you. The other person in the bug
clearly has some experience, and you refrained from answering him too. Oh well.

> >
> > > There are several components that need patching in order to work as
> >> expected with systemd:
> >> - polkit needs a patch that enables runtime detection of logind/consolekit
> >> - pambase needs to drop USE=systemd and always enable the optional
> >> module pam_systemd.so
> >
> > Again, what about people not using consolekit, nor logind, with no intention
> > of ever installing systemd? I've got nothing against this so long as it
> > is guaranteed not to break my pam setup. As-is I feel *very* wary of a change
> > that unconditionally requires a 'pam_systemd.so'. Please note I am not hostile
> > to your aims: I am merely seeking reassurance.
>
> Do you know how pam works? And did you understand the meaning of my
> words?

Again, you're not helping yourself with this attitude. Just a friendly warning.

> Do you know what optional means in this context?

"Always enable the optional.." means "require the currently optional.." to me.

> >> - genkernel needs to migrate to *udev (or as I did, provide a --udev
> >> genkernel option), mdev is unable to properly activate LVM volumes and
> >> LVM is actually working by miracle with openrc.
> >
> > Why is that such a "miracle"? openrc has worked with lvm since the beginning
> > afair, and is both clean, portable C, and modular.
>
> Do you know how LVM and udev and systemd interact wrt volumes activation?

I have a fair idea of how lvm, udev and openrc interact, after making udev start
after localmount last August. But really, all your replies are along the lines
of questioning my competence instead of answering the point.

I still don't see why you think it's a miracle openrc works with lvm, unless you
mean it was an effort for you. I do recall a bug with lvm a couple of months ago
I had to patch the lvm initscript for; but I notified the openrc channel about it
and they fixed it pretty quickly. Again, more experience that clearly makes me
incompetent.

> >> Alternatively, we should migrate to dracut.
> >> - networkmanager need not to install/remove files depending on
> >> USE=systemd but rather detect systemd at runtime, which is a 3 lines
> >> script.
> >
> > Sounds reasonable; since I don't use it, that can't affect me in any case.
>
> My goal wrt openrc is to keep the current level of support and just
> make systemd users' life easier.

<snip>

> >> If Gentoo is about choice, we should give our users the right to
> >> choose between the init system they like the most.
> >
> > I must be missing something as I thought they already had that choice.
>
> Please, write about something you actually manage to _know_. And also,
> please do read my post title.
> This is not a flamewar topic, I want to discuss about improving the
> systemd experience.

Hmm.. no. I'm afraid you haven't shown that Gentoo users don't currently have a
choice of init systems: so you're not some liberator endowing us with "rights"
we didn't otherwise enjoy til you came along with your magic impl, I'm afraid.

As for this topic being solely about improving the systemd experience, that's
a change. I could have sworn i read something about "improving the love between
openrc and systemd" and making *both* work better. But since you're now stating
this is just about systemd, I'll just point out that you're awfully territorial
yourself.

And your attitude of ignoring openrc people does not increase the love at all.

> > I am not doubting you: I just think we need more explanation of the exact
> > context where we can install Gentoo, but not a bootloader.
>
> Being Gentoo does not absolutely mean that we have to craft watches
> and play VHS with the tongue every time we want to do something.
> Making things easy is an orthogonal concept!

YAF non-answer.

> >> It looks like there is some consensus on the effort of making systemd
> >> more accessible,
> >
> > Sure there is: there's also consensus that this approach is wrong for
> > Gentoo. And I have to concur, without further reasoning from you. Switching
> > init isn't done that often, and when it is a Gentoo user is expected to
> > deal with configuration. In this case, it's a doddle to set the command-line
> > to init=/sbin/fubar to try it, and then when it's running the user can
> > change the symlink, or just revert as they choose.
> >
> > If they can't handle the above, they shouldn't be on Gentoo imo. And sabayon
> > already sets up systemd, so I don't see the use-case frankly. Apart from making
> > Gentoo base-system more suitable for direct usage in Sabayon, which is not our
> > problem.
>
> That's not absolutely the point, I am sorry. The topic here is to
> improve the systemd experience, if you are an openrc user that doesn't
> care about systemd and other stuff, you are off topic.

No the above is, and again you didn't answer it. There is no consensus as you claim.

> >
> > What are the effects for other downstreams? Funtoo for instance, has been
> > swimming against the upstream udev/systemd mania, from glancing at their site
> > recently. Have you consulted with other downstreams about their needs and got
> > buy-in from them too? That would strengthen your case, tho imo it's weak
> > irrespective of what systemd-preferring downstreams want: after all, they're
> > distros, not Gentoo users, and are supposed to be expert at setting things up.
> >
> > So I just don't see which Gentoo users this is helping. Making it even more
> > trivial to change init than it already is, is actually a bad thing in my eyes.
> > It gives the impression that it can be undertaken lightly which is simply bad
> > practice.
>
> We should stop thinking about Gentoo like a guru-distro. Gentoo is
> about choice, but choice != complexity. Making things easier is not
> against our Manifesto.

The thing you're ignoring is that your setup is more complex, and you clearly don't
give a damn about, and have not considered, the effect on other downstreams.

So we get more complexity and less choice overall, as is usual with idiot-box
approaches. And sorry, but a distro that doesn't hold your hand is a lot _easier_
to work with in the longer-term.

> Gentoo is about choice, which to me also means "embrace diversitiy".
> If you want to keep living in your little world, fine, you can and
> you're very welcome, but also people who want to have fun with new
> stuff should get the same respect.

You mean the respect you've shown me in this email, in my "little world"? *swoon*
you hero. I give up trying to be polite in the face of such crap, it's more than
I can stomach.

> Implementing new stuff also means making things easier, especially in the systemd case.

LMAO. You go girl, strut that nonsense like it means something.

> >> while there are problems with submitting bugs about
> >> new systemd units of the sort that maintainers just_dont_answer(tm).
> >> In this case, I am just giving 3 weeks grace period for maintainers to
> >> answer and then I usually go ahead adding units (I'm in systemd@ after
> >> all).
> >
> > AFAIK it's been policy for a while that systemd unit files should be installed
> > by default, for all the reasons you've given. I can't see a maintainer being
> > bothered by the systemd herd adding them when they have no interest: after all
> > users can already set an INSTALL_MASK, and it makes binpkgs more useful.
> >
>
> Thanks for reminding me a policy I am supposed to already know about.

So why are you complaining about maintainers who are not interested in systemd,
who ignore your bugs and don't add the unit files you want them to?

Maybe they know the policy too.

> >> The only remaining problem is about eselect-sysvinit, for this reason,
> >> I am probably going to create a new separate pkg called
> >> _sysvinit-next_, that contains all the fun stuff many developers were
> >> not allowed to commit (besides my needs, there is also the need of
> >> splitting sysvinit due to the issues reported in [4]). I am sure that
> >> a masked alternative sysvinit ebuild won't hurt anybody and will make
> >> Gentoo a bit more fun to use.
> >>
> >> The final outcome will hopefully be:
> >> - easier to migrate from/to systemd, at runtime, with NO recompilation
> >> at all (just enable USE=systemd and switch the device manager from
> >> *udev to systemd -- unless somebody wants to drop the udev part from
> >> systemd, if at all possible)
> >
> > How is adding USE=systemd to a system with it switched off (ie: enabling it),
> > *not* going to lead to recompilation?
> >
>
> Because you enable it once and for all and still have a _WORKING_ openrc.
> Please take more time reading about what's in my overlay before jumping the gun.

No way, sunshine. If you make what is effectively a marketing claim like "no
recompilation" then don't add the qualifications later on. Be precise upfront,
instead of typing so much noise. Or at very least be polite when someone queries
it.

> > What weird "emerge-fu"? You haven't outlined any at all. Unless you mean
> > changing a USE flag and the standard emerge process, which isn't what anyone
> > here would think of as "emerge-fu": just normal usage.
> >

> Same as above. You're talking about something you haven't even managed
> to try. I'm sorry to tell you.

Yes that's real emerge-fu there.. only for "gurus" for sure. </sarcasm>

If you post to a wider mailing-list like this, you should bear in mind that the
audience is not simply Gentoo developers, by _design_. If you don't like that, too
bad. Further, if you're posting to get feedback and buy-in from other people,
you severely limit yourself when you suddenly state that only those who have
already done the openrc -> systemd migration are qualified to discuss it. Doubly
so when you're rude to someone who actually felt quite supportive of your effort,
if not the design.

Believe me, I don't now. I just think you're a loud-mouthed amateur who's caught
up in the current fad for idiot-box designs, or what is traditionally known as
being "clever" instead of "wise". Your perspective will change in a decade or so.
As for me, I don't ever want to interact with you again.

> >> - we make possible to support new init systems in future, and even
> >> specific init wrappers (bootchart anyone?)
> >
> > Which is possible already, so this is null.
>
> It is not.

Right, so I can't switch init=/path/to/foo atm.

> >
> >> - we prepare the path towards a painless migration from consolekit
> >> (deprecated for long time now) to logind (we probably need to fork it
> >> off the systemd pkg -- upstream projects are _dropping_ consolekit
> >> support right now!)
> >
> > Some people don't use either. For good reason, but let's not get into a
> > flamewar: let's leave it as that "choice" thing you mentioned before. I
> > take it those users will not see any breakage beyond missing "features"?
>
> This doesn't affect such users.

Yay, a straight answer!

> >
> >> - we put back some fun into Gentoo
> >
> > Eh, I've been having much more fun since I got rid of semantic-craptop,
> > switched to mutt[A], and turned off all nubkit-related flags. My KDE came
> > back to me, and runs smooth just like 3.5 used to :) Then I replaced my
> > /bin/sh with /bin/bb which sped up bootup by an order of perceived
> > magnitude, and also sped up the _rest_ of my system. Of course, the latter
> > is only possible because Unix is designed on a modular basis, and we can
> > still swap components in and out on Linux (for now.)
>
> You're not the user I'm trying to work for. But yet nothing would
> change for you.

And interacting with you is not fun at all. Don't worry, I won't respond again
so feel free to mouth off some more.

> >
> >> If you want to see a working implementation of my systemd-love
> >> efforts, just go download [1] and see things working yourself.
> >>
> >> [1] http://www.sabayon.org/release/press-release-sabayon-1304
> >> [2] https://github.com/Sabayon/systemd-love
> >> [3] For instance: https://bugs.gentoo.org/show_bug.cgi?id=465236
> >> [4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615
> >
> > Again, I don't think you help your case with this remark. I expected the
> > "useless crap" to be a reference to lennart-ware. In fact, he was pointing
> > out that he told you all 8 months ago to raise it upstream: several commands
> > had already been migrated in upstream git according to another comment. So
> > the "useless crap" was in fact what he'd usually call whining ime, about the
> > lack of a "magic fix."
>
> Please join Gentoo first.

That's useless crap too. And in fact he told you all back in January last year, so
make that 13 months. Then bear in mind how users get treated, and how quickly so
many of us take things upstream. Then ask yourself how much respect your attitude
really merits.

> >
> > Please note: I fully support your effort to make it easy to switch back
> > and forth (I actually believe many people who try out openrc will stay with it.)
> > I just don't think that adding a fragile eselect module (along with "this needs
> > investigation" as things come up) is the way to do it. Nor does it solve
> > any real problem in the Gentoo context. Nor should someone change init on a whim,
> > without being ready to handle configuration.

> Thanks for your feedback.

Yeah, right. Thanks for answering none^W one of my questions.

Your designs sucks afaic, most especially within the Gentoo context. You're wasting
your time imo, but it's yours to waste. Unfortunately you're also going to waste the
time of users and other developers. Still that's their concern, and none of my business.
That's what I keep telling myself, then we get more and more nonsense from one
"developer" or another, along with the mantra "the source is out there" like we have the
time.

Just so long as I can keep hard-masking your rubbish, that's fine by me. When you're
in base-system, or you're a portage developer, I'll prepare the ground to switch
distros, contingent on the output and whether you're in charge of anything.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly.

["Paweł Hajdan, Jr."]

On 5/1/13 3:04 AM, Fabio Erculiani wrote:
> It is sad to say that the "territoriality" in base-system (and
> toolchain) is not allowing any kind of progress [3] [4]. This is
> nothing new, by the way.
>

> [4] "useless crap": https://bugs.gentoo.org/show_bug.cgi?id=399615

As far as I read the bug, Mike (vapier) is doing the right thing.
Distros doing lots of custom changes can only add more chaos to the picture.

Have you reached out to relevant upstreams? If they refuse to make
changes, that's a different story. So far I think it's reasonable to go
to upstreams first.

Paweł

[Michał Górny]

Well, the first thing to do would be making /sbin/init a symlink
and renaming sysvinit. Now, why would sysvinit upstream do such
a thing? I doubt it's a change that upstream should be willing to do
because of what downstream wants to do afterwards...

[Fabio Erculiani]

On Wed, May 1, 2013 at 9:52 PM, "Paweł Hajdan, Jr."
<phajd...@gentoo.org> wrote:
> On 5/1/13 3:04 AM, Fabio Erculiani wrote:
>
> As far as I read the bug, Mike (vapier) is doing the right thing.
> Distros doing lots of custom changes can only add more chaos to the picture.

We are a distribution, we have our own goals, thus we change the code
to better integrate with our ecosystem.
That's part of the game. If we don't want to do that, we shouldn't be
running a distro in the first place.

>
> Have you reached out to relevant upstreams? If they refuse to make
> changes, that's a different story. So far I think it's reasonable to go
> to upstreams first.

For just a symlink swap and some file moves? (re: sysvinit)
We don't need to bless upstream first for such small changes.

>
> Paweł
>
>



--
Fabio Erculiani

[Peter Stuge]

Fabio, I think you're doing awesome work!

Steven, I think you can behave a lot better on the internet. kthx.

Steven J. Long wrote:
> > It looks like there is some consensus on the effort of making systemd
> > more accessible,
>
> Sure there is: there's also consensus that this approach is wrong for
> Gentoo.

In my world naysayers have no say and doers decide, as long as there
are no obvious negative consequences from doing.

In my world it is also an absolute no-brainer to try to make systemd
as accessible as possible in Gentoo.

> Switching init isn't done that often

That doesn't mean that it couldn't be, and it also doesn't mean that
it wouldn't be handy to use eselect to do so.

> and when it is a Gentoo user is expected to deal with configuration.

I don't know where such expectation could come from since, as you
write, switching init isn't done that often; so there can't be a lot
of user feedback from doing it, and it hasn't been discussed very
much by developers.

If you mean that *you* expect users to deal with configuration then
that's fine and valid, but I think that if we can find a neat way for
users *not* to have to deal with configuration when they want to
switch init then that would be really nice!

> In this case, it's a doddle to set the command-line to
> init=/sbin/fubar to try it

I think it's less about telling the kernel which binary will be
process 1 and more about what gets started by process 1 on next boot.

> If they can't handle the above, they shouldn't be on Gentoo imo.

You have all right to your opinion, but I for one don't share this
opinion. If we can make it easy to switch around I think that's
awesome.

> I don't see the use-case frankly.

I would say that it is to make migration easy.

> So I just don't see which Gentoo users this is helping.

Anyone who has a Gentoo system using OpenRC who would like to try out
systemd.

> Making it even more trivial to change init than it already is, is
> actually a bad thing in my eyes.
> It gives the impression that it can be undertaken lightly which is
> simply bad practice.

Sorry, I don't buy your argument. Consider how lightly I can
undertake deletion of all my data, which is also bad practise:

rm -rf ~

> AFAIK it's been policy for a while that systemd unit files should
> be installed by default, for all the reasons you've given. I can't
> see a maintainer being bothered by the systemd herd adding them
> when they have no interest: after all users can already set an
> INSTALL_MASK, and it makes binpkgs more useful.

Yep, +1 for all of this. I think Fabio shouldn't let unresponsiveness
of others create very long wait states when doing benign changes.

> > The final outcome will hopefully be:
> > - easier to migrate from/to systemd, at runtime, with NO recompilation
> > at all (just enable USE=systemd and switch the device manager from
> > *udev to systemd -- unless somebody wants to drop the udev part from
> > systemd, if at all possible)
>
> How is adding USE=systemd to a system with it switched off (ie:
> enabling it), *not* going to lead to recompilation?

Setting the USE flag doesn't lead to recompilation per se, but the
question is good - what will the USE flag actually mean when we
arrive at the final outcome? Will it do anything at all? Fabio?

In the end, maybe it would just control if baselayout DEPENDs on
openrc or systemd?

> > - we make possible to support new init systems in future, and even
> > specific init wrappers (bootchart anyone?)
>
> Which is possible already, so this is null.

Consider that Fabio and I are not native english speakers. I would
recommend spending more time seeking to understand what was intended
to be transmitted, rather than merely interpreting the words received.

Communication becomes significantly more effectively that way, which
you probably don't need me to bring up, if you're used to talking to
users on forums. :)

> > - we put back some fun into Gentoo
>

> Eh, I've been having much more fun since ..
..

> the latter is only possible because Unix is designed on a modular
> basis, and we can still swap components in and out on Linux (for now.)

You are implicitly communicating that systemd can not be fun because
it is not modular. Basic flaming. What's the point of that?

> Please note: I fully support your effort to make it easy to switch
> back and forth

I have no doubts that this was true in your original email, but you
should consider that the words you chose communicate something very
different.

> I just don't think that adding a fragile eselect module (along with
> "this needs investigation" as things come up) is the way to do it.

I think the point is to investigate exactly to ensure that the module
*is not* fragile.

> Nor should someone change init on a whim, without being ready to
> handle configuration.

I think it would be awesome if we can allow changing init on a whim,
without having to handle configuration.

> In fact, dumbing down Gentoo is dangerous imo.

I think you misinterpret the intention. Creating powerful tools to
make complex tasks appear simpler doesn't fit my understanding of
"dumbing down." (My understanding is to artificially restrict what
tasks can be done.)

> Gentoo, like Unix, doesn't stop you from doing stupid things, as
> that would stop you doing clever things.

Switching init can be wise. (You later use "clever" in a derogatory
fashion.) I nearly replaced init with supervise on my systems before
I started using systemd. supervise is one of a few components I would
have written myself if I hadn't already found that someone else had
done it.

Steven J. Long wrote:
> Ah I see: sorry you're taking my email in the wrong spirit.

That is quite understandable to me, since you made liberal use of
flammable wording next to the explicit, but brief, expression of
support of the effort.

> I thought I made it quite clear I'm not hostile to your intentions,
> but you appear to be hostile to everything I've written.

See above. I think you could have communicated your points a lot
better, so that they would not have been misunderstood.

> > Have you ever tried to fully migrate to systemd from openrc? Clearly not.
>
> OFC not, that's the point: it's why I'm asking you.

I guess you realize that it isn't so useful to first educate peers
(answering you) before moving on to actual discussion. If you haven't
got experience from the details of this topic, perhaps your time is
better spent on another topic..

> > > Again, what about people not using consolekit, nor logind, with
> > > no intention of ever installing systemd?

They might change their mind at some point, and I think it would be
cool to make it as easy as possible to switch both ways.

> > > I've got nothing against this so long as it is guaranteed not
> > > to break my pam setup. As-is I feel *very* wary of a change
> > > that unconditionally requires a 'pam_systemd.so'. Please note I
> > > am not hostile to your aims: I am merely seeking reassurance.
> >
> > Do you know how pam works? And did you understand the meaning of
> > my words?
>
> Again, you're not helping yourself with this attitude. Just a
> friendly warning.

Your words are far from friendly.

I for one did not understand the meaning of Fabio's words, it would
be cool if he can clarify the details about the pam_systemd.so file.

> > Do you know what optional means in this context?
>
> "Always enable the optional.." means "require the currently
> optional.." to me.

I think this is a misunderstanding, because it doesn't fit with the
general intention I receive in Fabio's mail. I can't explain what
Fabio meant exactly, I believe I also don't quite understand what
he meant. I hope he'll clarify a bit.

> I still don't see why you think it's a miracle openrc works with lvm,

I think it's valid to ask for more details about potential problems
with openrc+lvm, although such details are also not really on topic
for this thread. (Very good to do in another thread however, maybe
there is also some misunderstanding about how openrc+lvm is supposed
to work, which would allow a smoother user experience and perhaps
improved documentation.)

> unless you mean it was an effort for you.

I don't see the point of this ad hominem.

> > Please, write about something you actually manage to _know_.

> > I want to discuss about improving the systemd experience.
>
> Hmm.. no.

What no? No you will not write about matters where you have
experience, or no you do not agree that this discussion is
about improving the systemd experience?

> I'm afraid you haven't shown that Gentoo users don't currently have
> a choice of init systems: so you're not some liberator endowing us
> with "rights" we didn't otherwise enjoy til you came along with
> your magic impl, I'm afraid.

I think you're behaving like an asshole, I don't see the point of that.

When studying systemd it becomes clear that there are potentially
interesting challenges in migration between process 1
implementations, and experience quickly confirms it. :)

I don't think Fabio has claimed to endow you with rights you didn't
have before, or enable new choice. I think he intends to make it
*easier* to effect one's choice. He points out several things which
would help accomplish this.

> As for this topic being solely about improving the systemd
> experience, that's a change. I could have sworn i read something
> about "improving the love between openrc and systemd" and making
> *both* work better. But since you're now stating this is just about
> systemd, I'll just point out that you're awfully territorial
> yourself.

I think "focused" is a better word. Since systemd is a new
alternative, and since it works differently in various ways, other
parts need to change to fit together with it. I think everyone agrees
that such changes should not have negative effects on already well-
established openrc.

> And your attitude of ignoring openrc people does not increase the
> love at all.

I for one don't see that attitude from Fabio. Can you be specific
about where openrc people (do you mean developers, users, or both?)
were ignored?

> > The topic here is to improve the systemd experience, if you are
> > an openrc user that doesn't care about systemd and other stuff,
> > you are off topic.
>
> No the above is,

Do you intend to say that Fabio is being off-topic in a thread he
himself started just two emails earlier?

> There is no consensus as you claim.

I think there is, it's just more local than I think you interpreted
Fabio to mean.

> > We should stop thinking about Gentoo like a guru-distro. Gentoo is
> > about choice, but choice != complexity. Making things easier is not
> > against our Manifesto.

Fabio makes excellent points here.

> The thing you're ignoring is that your setup is more complex,

Sorry, what do you mean? What setup is more complex than what alternative?

> and you clearly don't give a damn about, and have not considered,
> the effect on other downstreams.

That's not at all clear to me. What are some concrete negative
effects of Fabio's suggestions on "other downstreams," and which
downstreams do you have in mind?

> So we get more complexity and less choice overall,

I don't follow you. Please clarify? Tooling that simplifies switching
might end up complex, but only if the task itself actually requires
complexity. I don't understand the "less choice overall" part at all. :\

> as is usual with idiot-box approaches.

Another ad hominem, wheter against Fabio or Lennart this isn't a very
helpful comment in the discussion. It's clear that you aren't very
interested in making systemd work (easily) on Gentoo..

> And sorry, but a distro that doesn't hold your hand is a lot
> _easier_ to work with in the longer-term.

..from this comment and others. You could have saved us all a lot of
time if you had simply written a brief email saying something like

"I disagree with the goal of making it easier to switch from and to systemd."

along with some to-the-point qualification.

> I give up trying to be polite in the face of such crap, it's more
> than I can stomach.

If you can't compose yourself in the face of someone who doesn't seem
to understand you then please think twice before entering into
discussions. Misunderstandings are frequent on the internets.

> > Implementing new stuff also means making things easier, especially
> > in the systemd case.
>
> LMAO. You go girl, strut that nonsense like it means something.

Something is obviously meant, but you didn't receive it. I also
haven't received it. I don't know exactly what "new stuff" Fabio
refers to, but I can certainly think of things that he might have
intended to communicate, which allows his sentence above to have
wise meaning. Please try to think of such things you too.

> > >> while there are problems with submitting bugs about new
> > >> systemd units of the sort that maintainers just_dont_answer(tm).
> > >> In this case, I am just giving 3 weeks grace period
> > >

> > > AFAIK it's been policy
> >

> > Thanks for reminding me a policy I am supposed to already know about.
>
> So why are you complaining about maintainers who are not interested
> in systemd, who ignore your bugs and don't add the unit files you
> want them to?
>
> Maybe they know the policy too.

Fabio is being polite to give a grace period and it would be polite
of maintainers to answer, even if only to point out that they are
fine with him making the changes immediately.

It would be polite of them because it would remove a lot of wait
states. If there would be critical mass then at some point no new
wait states would be created. It is quite clear from my rather brief
experience with Gentoo developers that no matter what policy you have
to back you up you can make someone upset enough to flame you by
doing something that they don't like.

The wait states introduced by Fabio giving a grace period is a
typical example of the chilling effect which is a quite natural
result from such attitude.

It is what it is. Lots of software developers simply suck at dealing
with other people, and unfortunately this affects the software we all
work on, because most significant (open source) software development
is too much for any one person. Sad, but a fact.

> > Please take more time reading about what's in my overlay before
> > jumping the gun.
>
> No way, sunshine. If you make what is effectively a marketing claim
> like "no recompilation" then don't add the qualifications later on.
> Be precise upfront, instead of typing so much noise. Or at very
> least be polite when someone queries it.

Your query was not particularly polite either. I think it is
reasonable to ask for you to review Fabio's work before rejecting it.

> If you post to a wider mailing-list like this, you should bear in
> mind that the audience is not simply Gentoo developers, by _design_.
> If you don't like that, too bad.

Do you mean to say that because someone receives an email they don't
have a moral responsibility to consider if a reply will contribute
something to the topic, and a duty to optimize their reply for
efficiency for the sake of readers? I disagree with that.

> Further, if you're posting to get feedback and buy-in from other
> people, you severely limit yourself when you suddenly state that
> only those who have already done the openrc -> systemd migration
> are qualified to discuss it.

Maybe you agree that it's a lot less useful to discuss solutions
with someone who hasn't experienced the problem? It's not impossible,
in particular it's already very useful to discuss based on experience
from using openrc and systemd independently, since that already
forces thinking about the problem in concrete terms.

It's possible to come to same conclusions through theory, but that
usually takes significantly more effort. Our time as contributors is
scarce, so we tend to prefer conclusions drawn efficiently.

> Doubly so when you're rude to someone who actually felt quite
> supportive of your effort, if not the design.

I think Fabio reacted quite composed to your words, which were
indistinguishable from verbal attacks in spite of your explicit
expression of support.

> Believe me, I don't now. I just think you're a loud-mouthed amateur

You're writing what you think about Fabio, when the topic is making
it easier to switch process 1 implementations in Gentoo. Please focus.

> I don't ever want to interact with you again.

This is behaving like an asshole, which is harmful not only for Fabio
(which I guess you intend, but which I certainly don't find good) but
also for this mailing list and indeed the Gentoo project as a whole.

Please behave better than that.

> And interacting with you is not fun at all.

Volunteer contributor collaboration across nations, cultures and
languages using seven bit text is rarely fun - most of the time it's
damned hard work and requires boatloads of patience, to arrive at
even halfway good things.


> Your designs sucks afaic

I don't know about that. I think it sounds pretty good from a
usability perspective, and the way I understand Fabio's intentions
it also seems to make sense from a technical perspective.

> Just so long as I can keep hard-masking

What to mask is always your choice.

> your rubbish

I don't know about that, since again I didn't review Fabio's work.
But again, from what he describes it doesn't sound like rubbish to me.


> I'll .. switch distros

This statement creates a pretty bad atmosphere for little reason.


//Peter

[Matt Turner]

On Wed, May 1, 2013 at 2:40 PM, Peter Stuge <pe...@stuge.se> wrote:
> Steven, I think you can behave a lot better on the internet. kthx.

Amazing. I came to the exact opposite conclusion.

[Duncan]

Steven J. Long posted on Wed, 01 May 2013 19:52:03 +0100 as excerpted:

>> Gentoo is about choice, which to me also means "embrace diversitiy".
>> If you want to keep living in your little world, fine, you can and
>> you're very welcome, but also people who want to have fun with new
>> stuff should get the same respect.
>
> You mean the respect you've shown me in this email, in my "little
> world"? *swoon*
> you hero. I give up trying to be polite in the face of such crap, it's
> more than I can stomach.
>
>> Implementing new stuff also means making things easier, especially in
>> the systemd case.
>
> LMAO. You go girl, strut that nonsense like it means something.

> No way, sunshine. [...] Or at very least be polite when someone queries
> it.

Unfortunately, I believe the above demands a public post...

The above is taking it too far. Please take a bit of time to cool off if
you need it, then apologize, or if you choose not to do that, refrain
from further posts to the list.

(I don't necessarily agree with all he posted and in fact had some of the
same questions you did about optional being made non-optional, but
(despite the "little world" comment which I agree was going a bit far,
but just because he did, you didn't have to go one worse) he wasn't
getting personal to the degree you did above, and the elements of your
reply above simply have no place on this list. If indeed it is more than
you can stomach and you can't at least be polite and avoid going
personal, you really do need to consider getting off the list. The list
has been rather better lately as to their credit people /have/ been
keeping it civil despite obviously strong disagreements. There's no
place for this sort of personal name calling by analogy on this list now,
and despite past history to the contrary, never was or at least never
should have been. So if you insist on taking it to that level, do it
elsewhere.)

(Just to make clear I'm just a gentoo user and list participant too.
I've no authority to kick you from the list, but I can make clear that as
part of the gentoo community, /I/ don't like that behavior, and believe
it far enough out of bounds to ask for an apology. What others with said
authority do after that isn't up to me.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

[Alex Xu]

On 01/05/13 10:11 PM, Duncan wrote as excerpted:

> Steven J. Long posted on Wed, 01 May 2013 19:52:03 +0100 as excerpted:
>
>>> Gentoo is about choice, which to me also means "embrace diversitiy".
>>> If you want to keep living in your little world, fine, you can and
>>> you're very welcome, but also people who want to have fun with new
>>> stuff should get the same respect.
>>
>> You mean the respect you've shown me in this email, in my "little
>> world"? *swoon*
>> you hero. I give up trying to be polite in the face of such crap, it's
>> more than I can stomach.
>>
>>> Implementing new stuff also means making things easier, especially in
>>> the systemd case.
>>
>> LMAO. You go girl, strut that nonsense like it means something.
>
>> No way, sunshine. [...] Or at very least be polite when someone queries
>> it.
>
> Unfortunately, I believe the above demands a public post...
>
> The above is taking it too far. Please take a bit of time to cool off if
> you need it, then apologize, or if you choose not to do that, refrain
> from further posts to the list.
>

Agreed in full. I was prepared to write a response, but this is far more
eloquent than anything I could have written.

I'll go one step further, and say that this is just an example of the
toxic behavior that's been shown in the Gentoo community, in particular
this mailing list. This complete lack of any semblance of empathy, even
in some *Gentoo developers* is entirely unacceptable.

Things like "a bunch of crybabies", "whinging threads", "Avoid spreading
FUD", "Really, please stop spreading FUD." (from different people),
"Good arguments! As usual I'd say." (sarcasm), "Just to annoy people who
have successfully used...", ad nauseam are, at best, not remotely
productive.

Please, just consider for a second how your words will, or even /might/
be perceived by others. Even better: although it might seem beneath you,
consider how you yourself might perceive them, were they to be said from
someone else.

[William Hubbs]

I still don't see the advantage of eselect-sysvinit over editing your
boot loader configuration and changing the init= kcl option, as I said
on the bug.

William

[William Hubbs]

Like I've already said too, I don't see that we need to do this change.

Systemd is called /usr/lib/systemd/systemd (it should be
/lib/systemd/systemd), and sysvinit is called /sbin/init,, so I don't
see the need for moving init around and creating all of these symlinks.

I guess I'm not completely opposed to it, I just want you to convince me
that doing it has value. Where I am now is I feel like it adds
complexity for almost no gain.

William

[Kent Fredric]

On 2 May 2013 15:18, William Hubbs <will...@gentoo.org> wrote:

Like I've already said too, I don't see that we need to do this change.

Systemd is called /usr/lib/systemd/systemd (it should be
/lib/systemd/systemd), and sysvinit is called /sbin/init,, so I don't
see the need for moving init around and creating all of these symlinks.

I guess I'm not completely opposed to it, I just want you to convince me
that doing it has value. Where I am now is I feel like it adds
complexity for almost no gain.

William

The best arguments I have for the symlink approach, are:

- its a consistent approach that is bootloader agnostic

- it doesn't require you to understand your bootloaders scripting system to add it to the init= line

- its "no brains required, and hard to mess up"

bootloader configuration under grub1 for instance, was quite straight-forward. Now with grub-2, its quite convoluted, for me at least.

Its also sometimes a bit confusing if you need something other than /sbin/init as your "init", because sometimes you need some pre-init stuff ( like genkernel does ), and you need some /other/ parameter other than init= so that the pre-init still runs and then passes over to init

Having a symlink that will just do the right thing is helpful for these cases.

Against, the symlink may introduce parts that are breakable, like if user messes up and places the destination of the symlink on a different partition ( shouldn't be a problem, but might be ), or if you're doing an initird that has init baked into it, you'd have to regenerate that initrd after changing the symlink ( I think, maybe not, its probably not even a problem, its just something I'd have to check )

And also, if for whatever reason systemd becomes "unbootable" it might be slightly hard to boot with the "right" init if you can't change kernel parameters during boot time.

But noted, those last 2 "against" reasons are "edge cases", where the arguments for it are "majority cases", so collectively I'm still in favour of the eselect + symlinks approach.

--
Kent

[Fabio Erculiani]

On Thu, May 2, 2013 at 5:26 AM, Kent Fredric <kentf...@gmail.com> wrote:
>

[snip]

>
> Against, the symlink may introduce parts that are breakable, like if user
> messes up and places the destination of the symlink on a different partition
> ( shouldn't be a problem, but might be ), or if you're doing an initird that
> has init baked into it, you'd have to regenerate that initrd after changing
> the symlink ( I think, maybe not, its probably not even a problem, its just
> something I'd have to check )

eselect-sysvinit handles symlink swapping among files in /sbin/init.d.
So you cannot run into partitioning issues directly.

>
> And also, if for whatever reason systemd becomes "unbootable" it might be
> slightly hard to boot with the "right" init if you can't change kernel
> parameters during boot time.

The same happens if you change the boot arguments and reboot.
This is not something eselect-sysvinit is supposed to solve.

But anyway, eselect-sysvinit is a marginal thing and can be supported
by just providing a more experimental, perhaps masked, sysvinit
ebuild.
I am more concerned about the rest of the story.

>
> But noted, those last 2 "against" reasons are "edge cases", where the
> arguments for it are "majority cases", so collectively I'm still in favour
> of the eselect + symlinks approach.
>
>
> --
> Kent

--
Fabio Erculiani

[William Hubbs]

On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote:
> - its a consistent approach that is bootloader agnostic
> - it doesn't require you to understand your bootloaders scripting system to
> add it to the init= line

> - its "no brains required, and hard to mess up"

Why should we do something "boot loader agnostic" for the init
system when editing config files is something that all gentoo
users/sysadmins are expected to understand?

> bootloader configuration under grub1 for instance, was quite
> straight-forward. Now with grub-2, its quite convoluted, for me at least.

I haven't looked at grub2 yet, but I can't imagine it being convoluted
based on the documentation I have read.

> Its also sometimes a bit confusing if you need something other than
> /sbin/init as your "init", because sometimes you need some pre-init stuff (
> like genkernel does ), and you need some /other/ parameter other than init=
> so that the pre-init still runs and then passes over to init

Now you are talking about an initramfs, and no symlink is going to take
care of that.

You also still have to keep your boot loader configuration up to date
whenyou upgrade your kernel.

> Having a symlink that will just do the right thing is helpful for these
> cases.

I don't see how the symlink is going to help anything since it doesn't
preclude you editing your boot loader configuration.

> Against, the symlink may introduce parts that are breakable, like if user
> messes up and places the destination of the symlink on a different
> partition ( shouldn't be a problem, but might be ), or if you're doing an
> initird that has init baked into it, you'd have to regenerate that initrd
> after changing the symlink ( I think, maybe not, its probably not even a
> problem, its just something I'd have to check )
>
> And also, if for whatever reason systemd becomes "unbootable" it might be
> slightly hard to boot with the "right" init if you can't change kernel
> parameters during boot time.
>
> But noted, those last 2 "against" reasons are "edge cases", where the
> arguments for it are "majority cases", so collectively I'm still in favour
> of the eselect + symlinks approach.

If this does ever hit the tree, I think it should be defaulted to off
and users should be able to turn it on if they want.

William

[Mike Gilbert]

On Thu, May 2, 2013 at 2:05 PM, William Hubbs <will...@gentoo.org> wrote:
> On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote:
>> bootloader configuration under grub1 for instance, was quite
>> straight-forward. Now with grub-2, its quite convoluted, for me at least.
>
> I haven't looked at grub2 yet, but I can't imagine it being convoluted
> based on the documentation I have read.
>

If you manually write your own configuration for GRUB2, it is no more
convoluted than for GRUB Legacy.

If you use grub-mkconfig to generate a configuration file, you can
append the init option by setting
GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" in
/etc/default/grub.

Either way, it's pretty simple.

[Fabio Erculiani]

On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert <flo...@gentoo.org> wrote:
>
> If you manually write your own configuration for GRUB2, it is no more
> convoluted than for GRUB Legacy.
>
> If you use grub-mkconfig to generate a configuration file, you can
> append the init option by setting
> GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" in
> /etc/default/grub.

Not all the Gentoo users are as skilled as you (a developer). Having a
programmatic, bootloader agnostic way to swap /sbin/init is useful for
the reasons I explained. Yet I haven't read any solid reason not to do
that.

>
> Either way, it's pretty simple.
>

If it's that simple, why on earth do we have all the eselect modules we have!?

Extra modules:
audicle Manage /usr/bin/audicle audio engine
bashcomp Manage contributed bash-completion scripts
binutils Manage installed versions of sys-devel/binutils
blas Manage installed BLAS implementations
bzimage Switch bzImage default kernel by updating
/boot/bzImage symlink
cblas Manage installed CBLAS implementations
cdparanoia Manage /usr/bin/cdparanoia implementation
chuck Manage /usr/bin/chuck audio engine
ctags Manage /usr/bin/ctags implementations
ecj Manage ECJ targets
editor Manage the EDITOR environment variable
emacs Manage /usr/bin/emacs version
env Manage environment variables set in /etc/env.d/
esd Select esound daemon or wrapper
etags Manage /usr/bin/etags implementations
fontconfig Manage fontconfig /etc/fonts/conf.d/ symlinks
gnat Manage the installed gnat compilers
gnome-shell-extensions Manage default settings for systemwide
GNOME Shell extensions
infinality Manage the /etc/fonts/infinality/conf.d symlink
java-nsplugin Manage the Java plugin for Netscape-like Browsers
java-vm Manage the Java system and user VM
kernel Manage the /usr/src/linux symlink
lapack Manage installed LAPACK implementations
lcdfilter Manage the /etc/env.d/99lcdfilter symlink
lightdm Switch between LightDM greeters
locale Manage the LANG environment variable
maven Manage Maven targets
mesa Manage the OpenGL driver architecture used
by media-libs/mesa
miniaudicle Manage /usr/bin/miniAudicle audio engine
modules Query eselect modules
mpg123 Manage /usr/bin/mpg123 implementation
mpost Manage /usr/bin/mpost implementations
news Read Gentoo ("GLEP 42") news items
notify-send Manage /usr/bin/notify-send implementation
nxserver Manages the configuration of NX servers
oodict Manage the configuration of dictionaries
for OpenOffice.Org.
opencl Manage the OpenCL implementation used by your system
opengl Manage the OpenGL implementation used by your system
package-manager Manage the PACKAGE_MANAGER environment variable
pager Manage the PAGER environment variable
pdftex Manage /usr/bin/pdftex implementations
php Manage php installations
pinentry Manage /usr/bin/pinentry implementation
postgresql Manage active PostgreSQL client
applications and libraries
profile Manage the make.profile symlink
python Manage Python symlinks
qtgraphicssystem Manage the system-wide active Qt Graphics System
rails Manage Ruby on Rails versions
rc Manage /etc/init.d scripts in runlevels
ruby Manage Ruby symlinks
settingsd Switch between settingsd implementations
sh Manage /bin/sh (POSIX shell) implementations
sndpeek Manage /usr/bin/sndpeek audio engine
sysvinit Switch between sysvinit implementations
timidity Select default system patchset for TiMidity++
unison Manage /usr/bin/unison versions
vdr-plugin Manage VDR plugins
vi Manage /usr/bin/vi implementations
visual Manage the VISUAL environment variable
wxwidgets Manage the system default wxWidgets profile.
xvmc Manage the XvMC implementation used by your system

Why aren't we telling people to just edit config files!?

--
Fabio Erculiani

[Chí-Thanh Christopher Nguyễn]

Fabio Erculiani schrieb:

> Not all the Gentoo users are as skilled as you (a developer). Having a
> programmatic, bootloader agnostic way to swap /sbin/init is useful for
> the reasons I explained. Yet I haven't read any solid reason not to do
> that.

Another bootloader agnostic way is to pass init=.. via CONFIG_CMDLINE. Not
carrying more deviations from upstream than necessary is a worthwhile goal
for any sane distro. Especially when it has not even been attempted to get
this change merged upstream.

>> Either way, it's pretty simple.
>
> If it's that simple, why on earth do we have all the eselect modules we have!?

[...]

> Why aren't we telling people to just edit config files!?

I don't see your point? Besides eselect modules which manage symlinks when
users could instead edit configuration files, there exist eselect modules
which modify config files for the user, or those where symlinks are managed
without an equivalent editing of configuration files, or where symlinks are
managed in an upstream approved way.


Best regards,
Chí-Thanh Christopher Nguyễn

[Rich Freeman]

On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani <lx...@gentoo.org> wrote:
> Not all the Gentoo users are as skilled as you (a developer). Having a
> programmatic, bootloader agnostic way to swap /sbin/init is useful for
> the reasons I explained. Yet I haven't read any solid reason not to do
> that.

Well, there is no reason that an eselect module couldn't edit the boot
configuration, but not with the current way that everybody generates
them manually anyway.

Keep in mind that any Gentoo user who can't edit a boot loader
configuration is limited to booting from LiveCDs. The bootloader is
installed and configured manually in Gentoo, following the handbook.

Running openrc and systemd in parallel under grub legacy (the config
anybody without more exotic requirements and knowledge uses) is just a
matter of duplicating a few lines of the config file, renaming the
menu item name, and setting init= on one of them. Now you can boot
into either from the boot menu.

As I mentioned before on this list I'm all for having some packages
that actually install a working default kernel, initramfs, boot
config, etc. They might even be part of a profile, so that if a user
eselects that profile at install-time and does an emerge -uDN world
they can then just type reboot when it finishes and get a working
system. However, none of that exists now. If it did exist, then
manipulating those standardized files via eselect would be quite
possible as well (most likely the boot config would be built from some
kind of conf.d directory with a script that updates it when needed,
and eselect and other packages coudl dump stuff in that conf.d
directory as needed just as we do with env.d and so on). I should
probably take a few minutes to learn how all this was implemented in
Sabayon as it is likely a solved problem. Of course, the handbook
would just list this as another option and gentoo-sources and such
would never go away.

Rich

[Mike Gilbert]

On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani <lx...@gentoo.org> wrote:

> On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert <flo...@gentoo.org> wrote:
>>
>> If you manually write your own configuration for GRUB2, it is no more
>> convoluted than for GRUB Legacy.
>>
>> If you use grub-mkconfig to generate a configuration file, you can
>> append the init option by setting
>> GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" in
>> /etc/default/grub.
>
> Not all the Gentoo users are as skilled as you (a developer). Having a
> programmatic, bootloader agnostic way to swap /sbin/init is useful for
> the reasons I explained. Yet I haven't read any solid reason not to do
> that.
>

I was just providing some technical insight as the maintainer of that
package; I didn't mean to set off another tangent, but oh well.

Editing a configuration file does not require some great level of
skill. I think you give our users too little credit. Give them
good/simple documentation, and they can run with it.

I am not strongly opposed your eselect module for init; I just think
it is unnecessary. Adjusting a bootloader config is not the mystical
impossibility that you seem to make it out to be. If it were, we would
have automated it along with kernel building and initramfs generation.

>>
>> Either way, it's pretty simple.
>>
>
> If it's that simple, why on earth do we have all the eselect modules we have!?
>

> Why aren't we telling people to just edit config files!?
>

I guess people like writing eselect modules for no good reason? ;-)

Note that many of them do more than simply edit a configuration file.
Many do quite a bit of symlink manipulation, which is a good
application of eselect IMO.

[William Hubbs]

On Thu, May 02, 2013 at 03:39:25PM -0400, Mike Gilbert wrote:
> On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani <lx...@gentoo.org> wrote:
> > On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert <flo...@gentoo.org> wrote:
> >>
> >> If you manually write your own configuration for GRUB2, it is no more
> >> convoluted than for GRUB Legacy.
> >>
> >> If you use grub-mkconfig to generate a configuration file, you can
> >> append the init option by setting
> >> GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" in
> >> /etc/default/grub.
> >
> > Not all the Gentoo users are as skilled as you (a developer). Having a
> > programmatic, bootloader agnostic way to swap /sbin/init is useful for
> > the reasons I explained. Yet I haven't read any solid reason not to do
> > that.
> >
>
> I was just providing some technical insight as the maintainer of that
> package; I didn't mean to set off another tangent, but oh well.
>
> Editing a configuration file does not require some great level of
> skill. I think you give our users too little credit. Give them
> good/simple documentation, and they can run with it.

Agreed. All of our users who have installed Gentoo by following the
handbook know how to edit configuration files since there are several
they are required to edit as part of the installation process.

You have to do some work to maintain a Gentoo system. We are not and do
not claim to be a distro where everything "just works" out of the box.

> I am not strongly opposed your eselect module for init; I just think
> it is unnecessary. Adjusting a bootloader config is not the mystical
> impossibility that you seem to make it out to be. If it were, we would
> have automated it along with kernel building and initramfs generation.

Right. I think it is completely unnecessary given what we consider the
basic knowledge level of our users. It causes more work for the
developers with no gain for users.

William

[Kent Fredric]

On 3 May 2013 07:01, Fabio Erculiani <lx...@gentoo.org> wrote:

If it's that simple, why on earth do we have all the eselect modules we have!?

Hm, upon reading that list and seeing what they do, it raises another argument in favour of eselect:

If there needs to be more things changed prior to reboot than simply changing which init is invoked, having an eselect module gives a good place to put relevant related changes to make it work.

It also gives a good place to do sanity checks on your system so it knows that the change of init invocation will actually work on your machine.

--
Kent

[William Hubbs]

On Fri, May 03, 2013 at 08:27:36AM +1200, Kent Fredric wrote:
> On 3 May 2013 07:01, Fabio Erculiani <lx...@gentoo.org> wrote:
>
> >
> >
> > If it's that simple, why on earth do we have all the eselect modules we
> > have!?
> >
> >
> Hm, upon reading that list and seeing what they do, it raises another
> argument in favour of eselect:
>
> If there needs to be more things changed prior to reboot than simply
> changing which init is invoked, having an eselect module gives a good place
> to put relevant related changes to make it work.

There are no other changes in this case though; that's the point of this
discussion. You just emerge systemd and switch init= to the appropriate
path in your boot loader configuration, , or better yet, add a separate
entry to your boot loader configuration that boots you up with systemd
so that you can recover if things do not work.

If you use this symlink approach to actually switch your init to point
to systemd, then you boot and things don't work, you are hosed.

William

[Duncan]

Mike Gilbert posted on Thu, 02 May 2013 14:13:30 -0400 as excerpted:

> On Thu, May 2, 2013 at 2:05 PM, William Hubbs <will...@gentoo.org>
> wrote:
>> On Thu, May 02, 2013 at 04:26:06PM +1200, Kent Fredric wrote:
>>> bootloader configuration under grub1 for instance, was quite
>>> straight-forward. Now with grub-2, its quite convoluted, for me at
>>> least.
>>
>> I haven't looked at grub2 yet, but I can't imagine it being convoluted
>> based on the documentation I have read.
>>
>>
> If you manually write your own configuration for GRUB2, it is no more
> convoluted than for GRUB Legacy.

FWIW, this is the key to getting along with grub2. Its automated
configuration might arguably make simple things simple, but it makes the
(somewhat) complex /horribly/ complex and /terribly/ convoluted, to the
point it's nearly impossible.

So for those doing anything beyond the basics, just dumping the automated
config is from my experience the easiest way to go. FWIW, here I even
install-masked the automated config install app (grub2-mkconfig IIRC)
along with some of the then useless boilerplate config it installs for
it, so there's /no/ /possibility/ of it getting run accidentally,
overwriting my custom manual config.

FWIW, reminds me a lot of iptables, where there's all these tools that
promise to "simplify" things, but I found I was only more mixed up, until
I took the time to learn iptables itself, and write in its language
myself, thus eliminating all the convoluted middleware that attempted to
simplify the simple but ended up horribly convoluting anything beyond the
already simple. The automated grub2 stuff is IMO similar middleware that
only makes anything beyond the basics harder than it should be, without
simplifying the simple (at least to a gentooer) much at all.

[Chí-Thanh Christopher Nguyễn]

William Hubbs schrieb:

> If you use this symlink approach to actually switch your init to point
> to systemd, then you boot and things don't work, you are hosed.

Well, not fully hosed. You could still edit your kernel command line from
the boot loader pointing init=.. to the actual location and not the symlink
(or have a backup entry ready, but then any gains from switching symlinks
are negated).

[Luca Barbato]

On 05/01/2013 12:04 PM, Fabio Erculiani wrote:
> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST.
> THIS IS NOT A POST AGAINST OPENRC.

Amen

> With the release of Sabayon 13.04 [1] and thanks to the efforts I put
> into the systemd-love overlay [2], systemd has become much more
> accessible and easy to migrate to/from openrc. Both are able to
> happily coexist and logind/consolekit detection is now done at
> runtime.

> It is sad to say that the "territoriality" in base-system (and
> toolchain) is not allowing any kind of progress [3] [4]. This is
> nothing new, by the way.
>

> There are several components that need patching in order to work as
> expected with systemd:
> - polkit needs a patch that enables runtime detection of logind/consolekit
> - pambase needs to drop USE=systemd and always enable the optional
> module pam_systemd.so

> - genkernel needs to migrate to *udev (or as I did, provide a --udev
> genkernel option), mdev is unable to properly activate LVM volumes and

> LVM is actually working by miracle with openrc. Alternatively, we
> should migrate to dracut.

[unrelated] Do you have more insights about this part? mdev MUST work,
lots of thin recovery options are based on busybox.

> - networkmanager need not to install/remove files depending on
> USE=systemd but rather detect systemd at runtime, which is a 3 lines
> script.

Sounds sensible.

> - openrc-settingsd needs to support eselect-settingsd, which makes
> possible to switch the settingsd implementation at runtime, between
> openrc and systemd. This also removes the silly conflict between
> openrc-settingsd and systemd friends.

Would make sense merge init and settingsd in a single eselect or at
least make so switching init would warn if the settingsd doesn't match?

> - genkernel should at least support plymouth (work in progress my side)

Looking forward to it.

> - other ~490 systemd units are missing at this time and writing them
> could also be a great GSoC project (don't look at me, I'm busy
> enough).

Hopefully we might have a gsoc student volunteering to make a
runscript/lsb-script/systemd-unit compiler and a small abstraction so we
write a single init.d script and generate what's needed.
Probably we might even support pure-runit that way with minimal effort.

> It looks like there is some consensus on the effort of making systemd

> more accessible, while there are problems with submitting bugs about

> new systemd units of the sort that maintainers just_dont_answer(tm).

> In this case, I am just giving 3 weeks grace period for maintainers to
> answer and then I usually go ahead adding units (I'm in systemd@ after
> all).

See above.

> The only remaining problem is about eselect-sysvinit, for this reason,
> I am probably going to create a new separate pkg called
> _sysvinit-next_, that contains all the fun stuff many developers were
> not allowed to commit (besides my needs, there is also the need of
> splitting sysvinit due to the issues reported in [4]). I am sure that
> a masked alternative sysvinit ebuild won't hurt anybody and will make
> Gentoo a bit more fun to use.

Exactly, which is the problem at hand? I'd like to be able to safely
switch back and forth sysvinit and bb-init as well.

> The final outcome will hopefully be:
> - easier to migrate from/to systemd, at runtime, with NO recompilation
> at all (just enable USE=systemd and switch the device manager from
> *udev to systemd -- unless somebody wants to drop the udev part from
> systemd, if at all possible)

> - we give the users the right to choose without driving them nuts with
> weird emerge-fu.

> - we make possible to support new init systems in future, and even
> specific init wrappers (bootchart anyone?)

Here! o/ Currently in my list are

- bootchart2 (as an add-on to the other init systems)
- bb-init (requires different custom inittab)
- runit (openrc can use it instead thanks to benda xu past GSoC)

> - we prepare the path towards a painless migration from consolekit
> (deprecated for long time now) to logind (we probably need to fork it
> off the systemd pkg -- upstream projects are _dropping_ consolekit
> support right now!)

Again it is something I consider an option for a GSoC project, we have
already some openrc variant for other systemd-originated daemons in our
git.

> - we put back some fun into Gentoo

That's always good.

> If you want to see a working implementation of my systemd-love
> efforts, just go download [1] and see things working yourself.

Thank you a lot for your positive attitude and the huge effort =)

lu

[Rich Freeman]

On Sat, May 4, 2013 at 6:42 AM, Luca Barbato <lu_...@gentoo.org> wrote:
> Hopefully we might have a gsoc student volunteering to make a
> runscript/lsb-script/systemd-unit compiler and a small abstraction so we
> write a single init.d script and generate what's needed.
> Probably we might even support pure-runit that way with minimal effort.
>

I'm skeptical that this will ever make sense - both init systems have
features that it would make sense for units/scripts to make use of in
a more tailored fashion.

That said, if you really wanted to inter-convert, my gut feeling is
that it would be easier to go from a systemd unit to an init.d script,
and not the other way around. A systemd unit is more like a
specification - it describes the end result of what systemd should do.
An init.d script is an executable program - it can do virtually
anything even if they usually start out with a common skeleton. I
guess you could run the thing in a sandbox and carefully capture what
happens, and look in particular for calls to start-stop-daemon and
such, but it would be tricky.

The reality is that systemd units are floating around all over the
place - when I installed it on a Gentoo box I ended up just Googling
for already-written units for daemons that lacked them in Gentoo and
tweaked them. All that really need to happen is for those who use
systemd to submit them as bug attachments and maintainers should
commit them. Maybe a quick guide should be tossed together suggesting
the best way to install them (they're just text files in the proper
directory, but perhaps an eclass exists to take care of this).
Systemd units are much easier to write (typically) than init.d scripts
so this could be an area where end-users could contribute.

Rich

[Fabio Erculiani]

On Sat, May 4, 2013 at 12:42 PM, Luca Barbato <lu_...@gentoo.org> wrote:
> On 05/01/2013 12:04 PM, Fabio Erculiani wrote:
>> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST.
>> THIS IS NOT A POST AGAINST OPENRC.
>
> Amen
>
>> With the release of Sabayon 13.04 [1] and thanks to the efforts I put
>> into the systemd-love overlay [2], systemd has become much more
>> accessible and easy to migrate to/from openrc. Both are able to
>> happily coexist and logind/consolekit detection is now done at
>> runtime.
>> It is sad to say that the "territoriality" in base-system (and
>> toolchain) is not allowing any kind of progress [3] [4]. This is
>> nothing new, by the way.
>>
>> There are several components that need patching in order to work as
>> expected with systemd:
>> - polkit needs a patch that enables runtime detection of logind/consolekit
>> - pambase needs to drop USE=systemd and always enable the optional
>> module pam_systemd.so
>> - genkernel needs to migrate to *udev (or as I did, provide a --udev
>> genkernel option), mdev is unable to properly activate LVM volumes and
>> LVM is actually working by miracle with openrc. Alternatively, we
>> should migrate to dracut.
>
> [unrelated] Do you have more insights about this part? mdev MUST work,
> lots of thin recovery options are based on busybox.

Scenario:
- you have an initramfs with mdev, your pivot_chroot system runs udev.
- you have a LVM volume group, containing the lvm volume for / and
/home, and perhaps you also have swap on another volume.
- you boot using the current genkernel initramfs, which uses mdev and
comes with lvm support

The initramfs code activates your lvm volumes, lvm itself may or not
may be compiled with udev support. In the former case, nothing gets
written onto /run/udev (and devtmpfs), in the latter case, lvm writes
metadata that are useful to lvm itself to udev.
mdev is not udev, doesn't deal with udev rules so the metadata is
either pristine or completely unavailable.
busybox switches root and the boot starts: you obviously have lvm
compiled with udev there, since you're using udev (or systemd-udevd,
or gudev). The lvm there is either unable to find valid metadata so it
doesn't automatically activate the volumes (note: /home does not get
activated by the initramfs code) or, until some time ago but now
defaulted to off, lvm itself creates the device nodes (which should
have been created by udev + udev rules if lvm is compiled with udev
support).
If it's not enough, our current genkernel initramfs code (I fixed this
as well, it's in the systemd-love overlay) doesn't mount --move /run
to /newroot before switching root, so /run/udev is not ported over,
which means that even if mdev would have been able to do do all the
udev magic, things wouldn't work anyway.

Long story short, we should:
1) give up with cross compiler support in genkernel, which has been
anyway in a broken state for ages. Nobody is using it anyway.
2) make possible to optionally use udev in the initramfs (compiling
just for it is a pita and the trend here [dracut and others do this]
is to copy udevd from the system)
3) default to udev?

>
>> - networkmanager need not to install/remove files depending on
>> USE=systemd but rather detect systemd at runtime, which is a 3 lines
>> script.
>
> Sounds sensible.

Also, I forgot that I wrote a NetworkManager patch that makes it able
to detect logind/consolekit at runtime. It works and is in the
systemd-love overlay (it's a git format-patch patch).

>
>> - openrc-settingsd needs to support eselect-settingsd, which makes
>> possible to switch the settingsd implementation at runtime, between
>> openrc and systemd. This also removes the silly conflict between
>> openrc-settingsd and systemd friends.
>
> Would make sense merge init and settingsd in a single eselect or at
> least make so switching init would warn if the settingsd doesn't match?

They are really two separate things, even though I agree that it
should be made even easier. I don't think it's hard though.

>
>> - genkernel should at least support plymouth (work in progress my side)
>
> Looking forward to it.

I should have something ready soon.

>
>> - other ~490 systemd units are missing at this time and writing them
>> could also be a great GSoC project (don't look at me, I'm busy
>> enough).
>
> Hopefully we might have a gsoc student volunteering to make a
> runscript/lsb-script/systemd-unit compiler and a small abstraction so we
> write a single init.d script and generate what's needed.
> Probably we might even support pure-runit that way with minimal effort.
>
>> It looks like there is some consensus on the effort of making systemd
>> more accessible, while there are problems with submitting bugs about
>> new systemd units of the sort that maintainers just_dont_answer(tm).
>> In this case, I am just giving 3 weeks grace period for maintainers to
>> answer and then I usually go ahead adding units (I'm in systemd@ after
>> all).
>
> See above.
>
>> The only remaining problem is about eselect-sysvinit, for this reason,
>> I am probably going to create a new separate pkg called
>> _sysvinit-next_, that contains all the fun stuff many developers were
>> not allowed to commit (besides my needs, there is also the need of
>> splitting sysvinit due to the issues reported in [4]). I am sure that
>> a masked alternative sysvinit ebuild won't hurt anybody and will make
>> Gentoo a bit more fun to use.
>
> Exactly, which is the problem at hand? I'd like to be able to safely
> switch back and forth sysvinit and bb-init as well.

That's the only way to do it reliably and programmatically. Can you
imagine having to parse grub.cfg, lilo conf and only god knows what
else...?

--
Fabio Erculiani

[Fabio Erculiani]

I just forgot the tricky part.
If future lvm versions are going to use udev more extensively (for eg:
storing more critical metadata in it), the net result will be that
mdev won't work anymore. This is why I wrote that lvm is working "by
miracle for now".
mdev is not future proof wrt lvm support.

>
> --
> Fabio Erculiani



--
Fabio Erculiani

[Pacho Ramos]

El sáb, 04-05-2013 a las 15:05 +0200, Fabio Erculiani escribió:
[...]

> >> - networkmanager need not to install/remove files depending on
> >> USE=systemd but rather detect systemd at runtime, which is a 3 lines
> >> script.
> >
> > Sounds sensible.
>
> Also, I forgot that I wrote a NetworkManager patch that makes it able
> to detect logind/consolekit at runtime. It works and is in the
> systemd-love overlay (it's a git format-patch patch).

If you even has fixes... I would simply report a bug to
bugs.gentoo.org :/

[Luca Barbato]

On 05/04/2013 03:12 PM, Fabio Erculiani wrote:
> I just forgot the tricky part.
> If future lvm versions are going to use udev more extensively (for eg:
> storing more critical metadata in it), the net result will be that
> mdev won't work anymore. This is why I wrote that lvm is working "by
> miracle for now".
> mdev is not future proof wrt lvm support.

Sounds dangerously bad, I guess the response by the interested parties
(e.g. nas builders) will be moving lvm in bb or switch to dragonfly or
freebsd.

lu

[Luca Barbato]

On 05/04/2013 03:05 PM, Fabio Erculiani wrote:
> Long story short, we should:
> 1) give up with cross compiler support in genkernel, which has been
> anyway in a broken state for ages. Nobody is using it anyway.
> 2) make possible to optionally use udev in the initramfs (compiling
> just for it is a pita and the trend here [dracut and others do this]
> is to copy udevd from the system)
> 3) default to udev?

Uhm... sounds quite unpleasant and I'm really wondering why having udev
as middle-man for storing userspace metadata. The netlink broadcast
should be available to everybody for acting upon, using/extending it for
such tasks isn't possible?

lu

[Duncan]

Rich Freeman posted on Sat, 04 May 2013 08:54:16 -0400 as excerpted:

> On Sat, May 4, 2013 at 6:42 AM, Luca Barbato <lu_...@gentoo.org> wrote:
>> Hopefully we might have a gsoc student volunteering to make a
>> runscript/lsb-script/systemd-unit compiler and a small abstraction so
>> we write a single init.d script and generate what's needed.
>> Probably we might even support pure-runit that way with minimal effort.
>>
> I'm skeptical that this will ever make sense - both init systems have
> features that it would make sense for units/scripts to make use of in a
> more tailored fashion.

Same here. Sure, an automated conversion is possible and arguably might
serve as a starting point, but you're losing the best of both initsystems
in the process.

> That said, if you really wanted to inter-convert, my gut feeling is that
> it would be easier to go from a systemd unit to an init.d script, and
> not the other way around. A systemd unit is more like a specification -
> it describes the end result of what systemd should do.
> An init.d script is an executable program

You're a bit behind on openrc features, I think. =:^) It's actually
quite possible for openrc/runscript "scripts" to be written in a "spec-
style" format similar to systemd's unit files, just as it's possible for
systemd to run "legacy" shell-style scripts with little or no
modification, as some distros did with their initial conversion,
according to what I've read.

I think there's even some in-tree examples, tho I'm too lazy to go
looking ATM and their package maintainers and/or williamh would be more
familiar with them and could probably point them out off the top of their
head without looking.

> The reality is that systemd units are floating around all over the place
> - when I installed it on a Gentoo box I ended up just Googling for
> already-written units for daemons that lacked them in Gentoo and tweaked
> them.

That's what I have always figured I'd do, if I were to decide to convert
here before all the packages I init here had in-tree unit-files.

> Systemd units are much easier to write (typically) than init.d scripts
> so this could be an area where end-users could contribute.

See above. In theory it should be about even either way, since both
systemd and openrc can do either scripted or spec-style "units".
However, I expect systemd's "google resource" to be deeper in this
regard, both with regard to the units themselves and to documentation
about them, and the experience quotient probably favors systemd as well,
so in practice you're almost certainly right, if only from the previous
experience and googlable documentation and samples perspective.

[Fabio Erculiani]

Tracker bug:
https://bugs.gentoo.org/show_bug.cgi?id=468898

--
Fabio Erculiani

[Ben de Groot]

On 1 May 2013 18:04, Fabio Erculiani <lx...@gentoo.org> wrote:
> It looks like there is some consensus on the effort of making systemd
> more accessible, while there are problems with submitting bugs about
> new systemd units of the sort that maintainers just_dont_answer(tm).
> In this case, I am just giving 3 weeks grace period for maintainers to
> answer and then I usually go ahead adding units (I'm in systemd@ after
> all).

In my opinion you should not be asking maintainers to add systemd
units to their packages. They most likely do not have systems on which
they can test these, and very few users would need them anyway. I
would think it is better to add them to a separate systemd-units
package.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

[Chí-Thanh Christopher Nguyễn]

Ben de Groot schrieb:

> On 1 May 2013 18:04, Fabio Erculiani <lx...@gentoo.org> wrote:
>> It looks like there is some consensus on the effort of making systemd
>> more accessible, while there are problems with submitting bugs about
>> new systemd units of the sort that maintainers just_dont_answer(tm).
>> In this case, I am just giving 3 weeks grace period for maintainers to
>> answer and then I usually go ahead adding units (I'm in systemd@ after
>> all).
> In my opinion you should not be asking maintainers to add systemd
> units to their packages. They most likely do not have systems on which
> they can test these, and very few users would need them anyway. I
> would think it is better to add them to a separate systemd-units
> package.

Note that a similar thing is already done with the selinux policy packages.

Mostly the complaints against adding systemd units are that it would
unnecessarily clutter non-systemd installs. Users who complain are told
to set INSTALL_MASK but that is somewhat unwieldy.

A separate package for the unit file would solve this problem nicely.
Another option would be to add a "dounit" command to a future EAPI (like
doinitd today) and make portage install them unless FEATURES="nounit"
(like nodoc/noinfo/noman today).

[Ben de Groot]

On 8 May 2013 23:39, Fabio Erculiani <lx...@gentoo.org> wrote:

> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot <yng...@gentoo.org> wrote:
>> On 1 May 2013 18:04, Fabio Erculiani <lx...@gentoo.org> wrote:
>>> It looks like there is some consensus on the effort of making systemd
>>> more accessible, while there are problems with submitting bugs about
>>> new systemd units of the sort that maintainers just_dont_answer(tm).
>>> In this case, I am just giving 3 weeks grace period for maintainers to
>>> answer and then I usually go ahead adding units (I'm in systemd@ after
>>> all).
>>
>> In my opinion you should not be asking maintainers to add systemd
>> units to their packages. They most likely do not have systems on which
>> they can test these, and very few users would need them anyway. I
>
>> would think it is better to add them to a separate systemd-units
>> package.
>

> This sounds really wrong (tm) to me. It took me two weeks to kill that
> silly systemd-units pkg.
> All the distros around here do install systemd units with their
> packages and I believe that the council has already spoken about this.

It sounds more wrong to me to be asking normal package maintainers to
test and maintain unit files, while they don't use systemd themselves,
nor have it installed. Nor would most of our users need this.

And I believe the council has only spoken out against using a useflag
for installing such files. Afaik they haven't spoken out against a
systemd-units package. Please refer me to their decision if I'm wrong.

[Fabio Erculiani]

On Wed, May 8, 2013 at 5:26 PM, Ben de Groot <yng...@gentoo.org> wrote:

> On 1 May 2013 18:04, Fabio Erculiani <lx...@gentoo.org> wrote:
>> It looks like there is some consensus on the effort of making systemd
>> more accessible, while there are problems with submitting bugs about
>> new systemd units of the sort that maintainers just_dont_answer(tm).
>> In this case, I am just giving 3 weeks grace period for maintainers to
>> answer and then I usually go ahead adding units (I'm in systemd@ after
>> all).
>
> In my opinion you should not be asking maintainers to add systemd
> units to their packages. They most likely do not have systems on which
> they can test these, and very few users would need them anyway. I

> would think it is better to add them to a separate systemd-units
> package.

This sounds really wrong (tm) to me. It took me two weeks to kill that
silly systemd-units pkg.
All the distros around here do install systemd units with their
packages and I believe that the council has already spoken about this.

>

> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
> Gentoo Qt project lead, Gentoo Wiki admin
>

--
Fabio Erculiani

[Fabio Erculiani]

On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn
<chit...@gentoo.org> wrote:
> Ben de Groot schrieb:
>> On 1 May 2013 18:04, Fabio Erculiani <lx...@gentoo.org> wrote:
>>> It looks like there is some consensus on the effort of making systemd
>>> more accessible, while there are problems with submitting bugs about
>>> new systemd units of the sort that maintainers just_dont_answer(tm).
>>> In this case, I am just giving 3 weeks grace period for maintainers to
>>> answer and then I usually go ahead adding units (I'm in systemd@ after
>>> all).
>> In my opinion you should not be asking maintainers to add systemd
>> units to their packages. They most likely do not have systems on which
>> they can test these, and very few users would need them anyway. I
>> would think it is better to add them to a separate systemd-units
>> package.
>
> Note that a similar thing is already done with the selinux policy packages.

Upstreams will _DO_ ship systemd units at some point in future. It's a
completely different thing. Don't compare oranges to apples.

>
> Mostly the complaints against adding systemd units are that it would
> unnecessarily clutter non-systemd installs. Users who complain are told
> to set INSTALL_MASK but that is somewhat unwieldy.

Cluttering a system by just installing 4kb files? The council has
spoken. If you don't like the decision, I am sorry.
I can say the same for init scripts, they are freaking cluttering my
system and they're all over.
Or perhaps all these man pages, I don't need man pages locally but
still most ebuilds do install them. What do we do?

Let's be serious here.

>
> A separate package for the unit file would solve this problem nicely.

No, it will generate a gazillion of other problems. Like conflicts
arising every single day, just to name one.
Is that hard to do it right, as everybody else in this world does, and move on?

> Another option would be to add a "dounit" command to a future EAPI (like
> doinitd today) and make portage install them unless FEATURES="nounit"
> (like nodoc/noinfo/noman today).

Why all this mess!?

>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>

--
Fabio Erculiani

[Fabio Erculiani]

On Wed, May 8, 2013 at 5:49 PM, Ben de Groot <yng...@gentoo.org> wrote:
> On 8 May 2013 23:39, Fabio Erculiani <lx...@gentoo.org> wrote:
>> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot <yng...@gentoo.org> wrote:
>>> On 1 May 2013 18:04, Fabio Erculiani <lx...@gentoo.org> wrote:
>>>> It looks like there is some consensus on the effort of making systemd
>>>> more accessible, while there are problems with submitting bugs about
>>>> new systemd units of the sort that maintainers just_dont_answer(tm).
>>>> In this case, I am just giving 3 weeks grace period for maintainers to
>>>> answer and then I usually go ahead adding units (I'm in systemd@ after
>>>> all).
>>>
>>> In my opinion you should not be asking maintainers to add systemd
>>> units to their packages. They most likely do not have systems on which
>>> they can test these, and very few users would need them anyway. I
>>
>>> would think it is better to add them to a separate systemd-units
>>> package.
>>
>> This sounds really wrong (tm) to me. It took me two weeks to kill that
>> silly systemd-units pkg.
>> All the distros around here do install systemd units with their
>> packages and I believe that the council has already spoken about this.
>
> It sounds more wrong to me to be asking normal package maintainers to
> test and maintain unit files, while they don't use systemd themselves,
> nor have it installed. Nor would most of our users need this.

Nobody is asking maintainers to test units. The systemd team is
responsible for them.

>
> And I believe the council has only spoken out against using a useflag
> for installing such files. Afaik they haven't spoken out against a
> systemd-units package. Please refer me to their decision if I'm wrong.

I was referring to that.
We never mentioned a possible systemd-units package in any council
meeting I believe.
I hardly believe that the systemd team would accept such choice.

>
> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
> Gentoo Qt project lead, Gentoo Wiki admin
>

--
Fabio Erculiani

[Michael Mol]

On 05/08/2013 11:39 AM, Chí-Thanh Christopher Nguyễn wrote:
> Ben de Groot schrieb:
>> On 1 May 2013 18:04, Fabio Erculiani <lx...@gentoo.org> wrote:
>>> It looks like there is some consensus on the effort of making systemd
>>> more accessible, while there are problems with submitting bugs about
>>> new systemd units of the sort that maintainers just_dont_answer(tm).
>>> In this case, I am just giving 3 weeks grace period for maintainers to
>>> answer and then I usually go ahead adding units (I'm in systemd@ after
>>> all).
>> In my opinion you should not be asking maintainers to add systemd
>> units to their packages. They most likely do not have systems on which
>> they can test these, and very few users would need them anyway. I
>> would think it is better to add them to a separate systemd-units
>> package.
>
> Note that a similar thing is already done with the selinux policy packages.
>
> Mostly the complaints against adding systemd units are that it would
> unnecessarily clutter non-systemd installs. Users who complain are told
> to set INSTALL_MASK but that is somewhat unwieldy.
>
> A separate package for the unit file would solve this problem nicely.

Correct me if I'm wrong, but isn't your average ebuild file larger than
your average systemd unit file?

> Another option would be to add a "dounit" command to a future EAPI (like
> doinitd today) and make portage install them unless FEATURES="nounit"
> (like nodoc/noinfo/noman today).

I'm beginning to warm up to the idea of replacing most init scripts with
systemd unit files and a unit->init converter. This is obviously
nonsense if upstream provides init scripts, but I'm unsure how common
that is. (or even could be)

[Chí-Thanh Christopher Nguyễn]

Fabio Erculiani schrieb:

> Or perhaps all these man pages, I don't need man pages locally but
> still most ebuilds do install them. What do we do?

Users who don't want them set FEATURES="noman".

> Let's be serious here.

I assure you that I am fully serious.

>> Another option would be to add a "dounit" command to a future EAPI (like
>> doinitd today) and make portage install them unless FEATURES="nounit"
>> (like nodoc/noinfo/noman today).
> Why all this mess!?

Please elaborate why you think that a "dounit" command is a mess.

[Mike Gilbert]

On Wed, May 8, 2013 at 11:49 AM, Ben de Groot <yng...@gentoo.org> wrote:
> On 8 May 2013 23:39, Fabio Erculiani <lx...@gentoo.org> wrote:
>> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot <yng...@gentoo.org> wrote:
>>> On 1 May 2013 18:04, Fabio Erculiani <lx...@gentoo.org> wrote:
>>>> It looks like there is some consensus on the effort of making systemd
>>>> more accessible, while there are problems with submitting bugs about
>>>> new systemd units of the sort that maintainers just_dont_answer(tm).
>>>> In this case, I am just giving 3 weeks grace period for maintainers to
>>>> answer and then I usually go ahead adding units (I'm in systemd@ after
>>>> all).
>>>
>>> In my opinion you should not be asking maintainers to add systemd
>>> units to their packages. They most likely do not have systems on which
>>> they can test these, and very few users would need them anyway. I
>>
>>> would think it is better to add them to a separate systemd-units
>>> package.
>>
>> This sounds really wrong (tm) to me. It took me two weeks to kill that
>> silly systemd-units pkg.
>> All the distros around here do install systemd units with their
>> packages and I believe that the council has already spoken about this.
>
> It sounds more wrong to me to be asking normal package maintainers to
> test and maintain unit files, while they don't use systemd themselves,
> nor have it installed. Nor would most of our users need this.

I don't think we are actually asking you to test/maintain them; you
can treat them as a request for permission to perform a non-maintainer
commit.

If users run into problems, please feel free to copy/assign us on bugs.

> And I believe the council has only spoken out against using a useflag
> for installing such files. Afaik they haven't spoken out against a
> systemd-units package. Please refer me to their decision if I'm wrong.
>

Having a package to install every systemd unit in existence just
clutters the end user's system and makes it harder to tell which units
are actually valid.

Also, if a unit needs to be updated between versions of a given
package, that will lead to some strange looking deps.

A potential alternative would be to have a separate systemd-unit
package for each package in the tree, but that just seems like
overkill to me for a set of very small text files. And it still means
adding an optional runtime dep to the relevent packages.

[Mike Gilbert]

A working solution right now would be to set
INSTALL_MASK="/usr/lib/systemd/*". If you want to formalize this into
a portage feature, I have no objection.

The problem with a helper function is that it would miss cases where
the upstream build system actually installs the units.

[Ben de Groot]

On 8 May 2013 23:49, Fabio Erculiani <lx...@gentoo.org> wrote:
> On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn
> <chit...@gentoo.org> wrote:
>> Ben de Groot schrieb:
>>> On 1 May 2013 18:04, Fabio Erculiani <lx...@gentoo.org> wrote:
>>>> It looks like there is some consensus on the effort of making systemd
>>>> more accessible, while there are problems with submitting bugs about
>>>> new systemd units of the sort that maintainers just_dont_answer(tm).
>>>> In this case, I am just giving 3 weeks grace period for maintainers to
>>>> answer and then I usually go ahead adding units (I'm in systemd@ after
>>>> all).
>>> In my opinion you should not be asking maintainers to add systemd
>>> units to their packages. They most likely do not have systems on which
>>> they can test these, and very few users would need them anyway. I
>>> would think it is better to add them to a separate systemd-units
>>> package.
>>
>> Note that a similar thing is already done with the selinux policy packages.
>
> Upstreams will _DO_ ship systemd units at some point in future. It's a
> completely different thing. Don't compare oranges to apples.

Where upstreams ship systemd units, I don't think there is any issue.
The problem is you are asking Gentoo maintainers to add unit files
that upstream is not shipping. In this case we should test and
maintain these ourselves, which is an additional burden for very
little (if any) gain.

>>
>> Mostly the complaints against adding systemd units are that it would
>> unnecessarily clutter non-systemd installs. Users who complain are told
>> to set INSTALL_MASK but that is somewhat unwieldy.
>
> Cluttering a system by just installing 4kb files? The council has
> spoken. If you don't like the decision, I am sorry.
> I can say the same for init scripts, they are freaking cluttering my
> system and they're all over.
> Or perhaps all these man pages, I don't need man pages locally but
> still most ebuilds do install them. What do we do?
>
> Let's be serious here.

You are forgetting that OpenRC is, and will remain for the foreseeable
future, the default on Gentoo. Any systemd related files are
completely useless for most of our users. And those of us who consider
systemd a cancer do not want to see such files installed at all.

Gentoo is about choice and configurability. This means we will
accommodate both sides: so those who want to use an alternative init
system can do so, and those who want to avoid it can also keep doing
so.

>>
>> A separate package for the unit file would solve this problem nicely.
>
> No, it will generate a gazillion of other problems. Like conflicts
> arising every single day, just to name one.

I think you are making the problem bigger than it is. Are there really
that many packages that need a unit file, but upstream doesn't ship
them yet, and many that are in the process of changing that? Either
way, it should be an easy fix for systemd enthusiasts.

> Is that hard to do it right, as everybody else in this world does, and move on?

Gentoo is different. If we should do what everybody else does, then
there is no reason for our existence.

>> Another option would be to add a "dounit" command to a future EAPI (like
>> doinitd today) and make portage install them unless FEATURES="nounit"
>> (like nodoc/noinfo/noman today).
>
> Why all this mess!?

You know very well why.

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I am generally in agreement with this. If the systemd unit file is
provided by upstream, then i think it's absolutely reasonable for the
gentoo dev to be expected to package it along with everything else,
however if the systemd unit file is NOT included from upstream, and
the gentoo dev doesn't have any experience with systemd nor any test
bed to maintain the script, then expecting or requiring them to
include it is not reasonable to me imo.

If they optionally want to anyways, of course, more power to them, and
there's probably no reason not to have a bug filed about it (at say,
the 'enhancement' level).







-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGKfO8ACgkQ2ugaI38ACPD7UgEAhPnkxm465nrnLrm/rbaYp7l2
Mk2OZic0KCmar9Ro82cA/RyUTF7OnnTAPON2/AregSm2Ut9VtQqex6C1qjvrjR2u
=Wv/H
-----END PGP SIGNATURE-----

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/05/13 12:06 PM, Mike Gilbert wrote:
> On Wed, May 8, 2013 at 11:49 AM, Ben de Groot <yng...@gentoo.org>
> wrote:
>> On 8 May 2013 23:39, Fabio Erculiani <lx...@gentoo.org> wrote:
>>> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot
>>> <yng...@gentoo.org> wrote:
>>>
>>> This sounds really wrong (tm) to me. It took me two weeks to
>>> kill that silly systemd-units pkg. All the distros around here
>>> do install systemd units with their packages and I believe that
>>> the council has already spoken about this.
>>
>> It sounds more wrong to me to be asking normal package
>> maintainers to test and maintain unit files, while they don't use
>> systemd themselves, nor have it installed. Nor would most of our
>> users need this.
>
> I don't think we are actually asking you to test/maintain them;
> you can treat them as a request for permission to perform a
> non-maintainer commit.
>
> If users run into problems, please feel free to copy/assign us on
> bugs.

This could work; although such a thing implies a bit of a different
dynamic than i've seen occurring with anything else... So to be
clear, the proposal here is that systemd team/herd would be CC'd on
all systemd related bugs and handle all non-upstream systemd unit files?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGKfoQACgkQ2ugaI38ACPASKgD/TjIEK3QBUjq9ONA7dX/x7xRK
1iRXVlYX9R8OTuX62twBAKgw7L5CaKX1agiPY2Zhu0jvf3x1Ag6kYy8o4wrcnHax
=N6Uk
-----END PGP SIGNATURE-----

[Rich Freeman]

On Wed, May 8, 2013 at 11:26 AM, Ben de Groot <yng...@gentoo.org> wrote:
> In my opinion you should not be asking maintainers to add systemd
> units to their packages. They most likely do not have systems on which
> they can test these, and very few users would need them anyway. I
> would think it is better to add them to a separate systemd-units
> package.

I think that makes about as much sense as putting openrc init.d
scripts in a separate package.

I'm contemplating migrating to systemd and when that happens I'll
generally no longer be testing openrc init.d scripts in packages I
maintain. That doesn't mean that I plan to drop them, or that I won't
investigate bugs that get reported. As more migrate to systemd I
suspect this will become a fairly common issue.

Maintainers who don't use systemd need to deal with unit files in the
same way that maintainers who don't use desktop environments need to
deal with .desktop entries. There is no requirement that packages
include these, but they're valid bugs when others submit them and
maintainers are encouraged to include them. You can always ask
somebody else to test them for you, and nobody is going to give you a
hard time as the only people impacted by a broken unit file are
systemd users who would not be better off if the unit file wasn't
included.

Sure, OpenRC is the default, but developers aren't required to include
init.d scripts any more than they're required to include systemd
units. If 70% of the developers eventually migrate and you want to
hold onto OpenRC do you really want them to ignore your requests to
include init.d scripts where they make sense?

Rich

[Chí-Thanh Christopher Nguyễn]

Mike Gilbert schrieb:

> On Wed, May 8, 2013 at 12:06 PM, Chí-Thanh Christopher Nguyễn
> <chit...@gentoo.org> wrote:
>> Fabio Erculiani schrieb:
>>> Or perhaps all these man pages, I don't need man pages locally but
>>> still most ebuilds do install them. What do we do?
>> Users who don't want them set FEATURES="noman".
>>
>>> Let's be serious here.
>> I assure you that I am fully serious.
>>
>>>> Another option would be to add a "dounit" command to a future EAPI (like
>>>> doinitd today) and make portage install them unless FEATURES="nounit"
>>>> (like nodoc/noinfo/noman today).
>>> Why all this mess!?
>> Please elaborate why you think that a "dounit" command is a mess.
>>
> A working solution right now would be to set
> INSTALL_MASK="/usr/lib/systemd/*".

Yes, I mentioned INSTALL_MASK in a previous reply. It is however
unwieldy and has the potential of unintended side effects. This is e.g.
why I chose a USE=savedconfig approach for sys-kernel/linux-firmware.

> If you want to formalize this into
> a portage feature, I have no objection.

Ok, done:
https://bugs.gentoo.org/show_bug.cgi?id=469086

> The problem with a helper function is that it would miss cases where
> the upstream build system actually installs the units.

I think that is another issue, similar to packages directly installing
init scripts or ldconfig or .desktop files. Sometimes this is ok, and
sometimes maintainers prevent that. Not sure what would be the preferred
way for systemd units.

[Arun Raghavan]

On 8 May 2013 21:51, Ben de Groot <yng...@gentoo.org> wrote:
[...]

> Where upstreams ship systemd units, I don't think there is any issue.
> The problem is you are asking Gentoo maintainers to add unit files
> that upstream is not shipping. In this case we should test and
> maintain these ourselves, which is an additional burden for very
> little (if any) gain.

The burden is not on the package maintainers, but on the systemd team.
The perception of gain is entirely yours (and clearly biased).

>>> Mostly the complaints against adding systemd units are that it would
>>> unnecessarily clutter non-systemd installs. Users who complain are told
>>> to set INSTALL_MASK but that is somewhat unwieldy.
>>
>> Cluttering a system by just installing 4kb files? The council has
>> spoken. If you don't like the decision, I am sorry.
>> I can say the same for init scripts, they are freaking cluttering my
>> system and they're all over.
>> Or perhaps all these man pages, I don't need man pages locally but
>> still most ebuilds do install them. What do we do?
>>
>> Let's be serious here.
>
> You are forgetting that OpenRC is, and will remain for the foreseeable
> future, the default on Gentoo. Any systemd related files are
> completely useless for most of our users. And those of us who consider
> systemd a cancer do not want to see such files installed at all.

The overhead of the files' presence is trivial, and most users won't
care. Those who do care have a trivial line to add in make.conf, and
that is for the small number of people who share your vitriol for the
systemd project.

> Gentoo is about choice and configurability. This means we will
> accommodate both sides: so those who want to use an alternative init
> system can do so, and those who want to avoid it can also keep doing
> so.

This is a strawman. What Fabio is doing provides more choice, so fits
your "Gentoo is about choice" criterion. Making the people who wish to
provide this choice jump through hoops merely for personal dislike of
the project on the other hand violates this tenet that we all seem to
be so fond of.

-- Arun

[Michał Górny]

On Wed, 8 May 2013 23:26:57 +0800

Ben de Groot <yng...@gentoo.org> wrote:

> On 1 May 2013 18:04, Fabio Erculiani <lx...@gentoo.org> wrote:
> > It looks like there is some consensus on the effort of making systemd
> > more accessible, while there are problems with submitting bugs about
> > new systemd units of the sort that maintainers just_dont_answer(tm).
> > In this case, I am just giving 3 weeks grace period for maintainers to
> > answer and then I usually go ahead adding units (I'm in systemd@ after
> > all).
>
> In my opinion you should not be asking maintainers to add systemd
> units to their packages. They most likely do not have systems on which
> they can test these, and very few users would need them anyway. I
> would think it is better to add them to a separate systemd-units
> package.

How would that package handle unit files differing per package
versions? For example, changed options, relocated executables...

--
Best regards,
Michał Górny

[Michael Mol]

It would effectively need to be bumped every time any package added,
removed or changed a unit file requirement. Also every time a unit
file-bearing package is added or removed from tree.

That would be one insanely hot package.

[Michał Górny]

On Thu, 9 May 2013 00:21:53 +0800

Ben de Groot <yng...@gentoo.org> wrote:

It is quite likely that OpenRC will start supporting unit files soon.
Then in many cases we will be able to strip down this to just one init
format which would satisfy both init systems.

Of course, people who are thoughtlessly removing all systemd files
for the sake of 4 KiB will suffer then.

[Rich Freeman]

On Wed, May 8, 2013 at 1:18 PM, Michael Mol <mik...@gmail.com> wrote:
> It would effectively need to be bumped every time any package added,
> removed or changed a unit file requirement. Also every time a unit
> file-bearing package is added or removed from tree.
>
> That would be one insanely hot package.

Splitting out unit files might have made sense when systemd was a
highly experimental piece of software that a few people are tinkering
with. It is rapidly becoming the most commonly used init.d-like
implementation out there (mainly by virtue of the fact that every
other one tends to be used by a single distro). Quite a few are using
it on Gentoo.

I think it really needs to be accommodated in the same way as openrc
init.d scripts. I'm not saying that maintainers should be required to
create them if they're missing (they don't even have to do that for
openrc init.d scripts). However, if users or other devs contribute
them and vouch that they work, then they should be included in
packages.

This really isn't any difference from the myriad of unusual
configurations that Gentoo supports. If somebody on the Prefix team
suggests some changes to my ebuild to make it more Prefix-friendly I
collaborate with them. I don't need to get Prefix working on a sparc
to accept their input that some change to the ebuild makes life easier
on this arch. Sure, I'll make sure we're not adding regressions, but
this is a community effort. The same is true if I get a bug that some
package I maintain has some problem on hardware I don't own (like a
different graphics card). I can't test it, but I can work with what
I'm given and call for testing and so on.

Bottom line is that none of this should really be inconveniencing
maintainers much - nobody is required to create unit files. However,
if a friendly user submits a bug with one attached, then the
maintainer should strongly consider adding them to the package at the
next convenient time.

Nobody has to use systemd if they don't want to, but honestly, it
seems like it is slowly taking over. It sounds like OpenRC will
support compatible unit files, and that is really a win-win all around
as it means that users of both platforms will benefit from work
invested on the other. That will mean that those who want to stick
with OpenRC/Eudev/whatever will have a good experience even if many
devs abandon those platforms, and vice-versa.

Rich

[Michał Górny]

Please note that stable & unstable versions of packages may require
different units.

[William Hubbs]

I'm going to have to agree with Fabio on this one.

A systemd-units package is not a good idea. The eventual goal is to get
the systemd units into the upstream packages.

Thanks,

William

[William Hubbs]

As was said above, the distro policy is that we always install
configuration files. This is how we handle logrotate and xinetd among
other things.

I would like to see the logrotate, xinet and systemd use flags used for
this, but to get that to happen we need to change the policy -- you do
that by putting this on the agenda for the council.

If we do this, I would rather change it across the board and not just
for systemd. So, this would mean adding an openrc use flag to every
ebuild that installs openrc init scripts and using it to control that as
well.

> Gentoo is about choice and configurability. This means we will
> accommodate both sides: so those who want to use an alternative init
> system can do so, and those who want to avoid it can also keep doing
> so.

The argument in the past has been that we aren't taking away the choice
and configurability since we have INSTALL_MASK.

> >>
> >> A separate package for the unit file would solve this problem nicely.
> >
> > No, it will generate a gazillion of other problems. Like conflicts
> > arising every single day, just to name one.
>
> I think you are making the problem bigger than it is. Are there really
> that many packages that need a unit file, but upstream doesn't ship
> them yet, and many that are in the process of changing that? Either
> way, it should be an easy fix for systemd enthusiasts.

Having separate packages for systemd units that we ship would be pretty
unwieldy. I can see advantages to it, but I can definitely also see
disadvantages. This same thinking could apply to OpenRC init scripts as
well.

William

[Pacho Ramos]

El mié, 08-05-2013 a las 23:49 +0800, Ben de Groot escribió:
[...]

> It sounds more wrong to me to be asking normal package maintainers to
> test and maintain unit files, while they don't use systemd themselves,
> nor have it installed. Nor would most of our users need this.
>
> And I believe the council has only spoken out against using a useflag
> for installing such files. Afaik they haven't spoken out against a
> systemd-units package. Please refer me to their decision if I'm wrong.
>
> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
> Gentoo Qt project lead, Gentoo Wiki admin
>
>

And, why not allow systemd team (or systemd-units@g.o if it's created)
to test and add the unit files to each affected package? If the reported
bug is caused by unit file, that team could handle it

[Walter Dnes]

On Wed, May 08, 2013 at 11:49:18PM +0800, Ben de Groot wrote

> And I believe the council has only spoken out against using a useflag
> for installing such files. Afaik they haven't spoken out against a
> systemd-units package. Please refer me to their decision if I'm wrong.

Wouldn't the "systemd" USE flag be the appropriate one to key on?
The description in /usr/portage/profiles/use.desc says...

systemd - Enable use of systemd-specific libraries and features like
socket activation or session tracking

Surely, units files qualify as "systemd-specific features".

--
Walter Dnes <walt...@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[Jeroen Roovers]

On Wed, 8 May 2013 21:48:36 -0400
"Walter Dnes" <walt...@waltdnes.org> wrote:

> Wouldn't the "systemd" USE flag be the appropriate one to key on?
> The description in /usr/portage/profiles/use.desc says...
>
> systemd - Enable use of systemd-specific libraries and features like
> socket activation or session tracking
>
> Surely, units files qualify as "systemd-specific features".

https://bugs.gentoo.org/show_bug.cgi?id=198901


jer

[Walter Dnes]

On Wed, May 08, 2013 at 10:31:21PM +0530, Arun Raghavan wrote

> The overhead of the files' presence is trivial, and most users won't
> care. Those who do care have a trivial line to add in make.conf, and
> that is for the small number of people who share your vitriol for the
> systemd project.

Then howsabout a "units" ebuild that installs all available units
files for systemd users? "The overhead of the files' presence is
trivial, and most systemd users won't care".

The thread title says it all... normal Gentoo users don't use systemd.

[Canek Peláez Valdés]

On Wed, May 8, 2013 at 9:18 PM, Walter Dnes <walt...@waltdnes.org> wrote:
> On Wed, May 08, 2013 at 10:31:21PM +0530, Arun Raghavan wrote
>
>> The overhead of the files' presence is trivial, and most users won't
>> care. Those who do care have a trivial line to add in make.conf, and
>> that is for the small number of people who share your vitriol for the
>> systemd project.
>
> Then howsabout a "units" ebuild that installs all available units
> files for systemd users? "The overhead of the files' presence is
> trivial, and most systemd users won't care".
>
> The thread title says it all... normal Gentoo users don't use systemd.

For now.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[Anthony G. Basile]

People keep saying disk space is not an issue but it is on embedded
systems. Even 4k or one i-node. So the choice to not install unit
files is important. I'm sympathetic to the idea of reducing use flags
and I would really not like to see USE="openrc" or "systemd" everywhere.
Without having tested, it does seem that INSTALL_MASK is sufficient.
I recommend going that route and documenting it.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

[Rich Freeman]

On Wed, May 8, 2013 at 10:18 PM, Walter Dnes <walt...@waltdnes.org> wrote:
> On Wed, May 08, 2013 at 10:31:21PM +0530, Arun Raghavan wrote
>
>> The overhead of the files' presence is trivial, and most users won't
>> care. Those who do care have a trivial line to add in make.conf, and
>> that is for the small number of people who share your vitriol for the
>> systemd project.
>
> Then howsabout a "units" ebuild that installs all available units
> files for systemd users? "The overhead of the files' presence is
> trivial, and most systemd users won't care".

Read the rest of the thread and the archives. Both suggestions have
been discussed and they're not practical. Your first suggestion was
specifically rejected by the council. Your second one was suggested
only yesterday in this very same thread.

>
> The thread title says it all... normal Gentoo users don't use systemd.

There is no such thing as a "normal Gentoo user." About the closest
you'll come is a hypothetical Gentoo user who doesn't touch
/etc/portage. I suspect that the time will be approaching soon that
there will be more development/testing targeting systemd than OpenRC
on Gentoo. I'm sure the default will remain as-is for a long-time.
For how many years was the typical developer running OpenRC while the
typical user was running baselayout 1?

The goal is to make systemd a first class citizen in Gentoo, nothing
more. Developers will not be required to run it, or test on it, just
as they aren't required to run or test on OpenRC or FreeBSD (two other
first-class citizens in Gentoo).

If you don't want unit files installed, just use INSTALL_MASK as
endorsed by the Council. Ditto for docs, or init.d files, or
whatever.

Rich

[Michał Górny]

On Thu, 09 May 2013 05:56:42 -0400
"Anthony G. Basile" <bas...@opensource.dyc.edu> wrote:

> On 05/08/2013 10:01 PM, Jeroen Roovers wrote:
> > On Wed, 8 May 2013 21:48:36 -0400
> > "Walter Dnes" <walt...@waltdnes.org> wrote:
> >
> >> Wouldn't the "systemd" USE flag be the appropriate one to key on?
> >> The description in /usr/portage/profiles/use.desc says...
> >>
> >> systemd - Enable use of systemd-specific libraries and features like
> >> socket activation or session tracking
> >>
> >> Surely, units files qualify as "systemd-specific features".
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=198901
>

> People keep saying disk space is not an issue but it is on embedded
> systems. Even 4k or one i-node. So the choice to not install unit
> files is important. I'm sympathetic to the idea of reducing use flags
> and I would really not like to see USE="openrc" or "systemd" everywhere.
> Without having tested, it does seem that INSTALL_MASK is sufficient.
> I recommend going that route and documenting it.

We should probably consider extending the INSTALL_MASK a bit. A good
idea would be to allow repositories to pre-define names
for INSTALL_MASK (alike USE flags) and allow portage to control them
over those names.

A similar variant is implemented in app-portage/install-mask which maps
names obtained from ${FILESDIR} to paths.

[Rich Freeman]

On Thu, May 9, 2013 at 12:44 PM, Michał Górny <mgo...@gentoo.org> wrote:
> We should probably consider extending the INSTALL_MASK a bit. A good
> idea would be to allow repositories to pre-define names
> for INSTALL_MASK (alike USE flags) and allow portage to control them
> over those names.

We'd need a corresponding way to unmask stuff as well, if we went that
route. It would add value for stuff like the embedded profile, but I
wouldn't want to see it used in the base profiles.

Rich

[Pacho Ramos]

El jue, 09-05-2013 a las 18:44 +0200, Michał Górny escribió:
[...]

> A similar variant is implemented in app-portage/install-mask which maps
> names obtained from ${FILESDIR} to paths.
>

Didn't know that utility :O, thanks! (maybe, at least, a blog entry
could have been added when you did this tool ;))

[Steven J. Long]

Rich Freeman wrote:
> I think it really needs to be accommodated in the same way as openrc
> init.d scripts. I'm not saying that maintainers should be required to
> create them if they're missing (they don't even have to do that for
> openrc init.d scripts). However, if users or other devs contribute
> them and vouch that they work, then they should be included in
> packages.

++ absolutely.

And if you want to change init=, edit the file, from a script if you wish
to automate it, after checking that everything is in-place.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[Ralph Sennhauser]

On Wed, 8 May 2013 13:37:51 -0400
Rich Freeman <ri...@gentoo.org> wrote:

> Bottom line is that none of this should really be inconveniencing
> maintainers much - nobody is required to create unit files. However,
> if a friendly user submits a bug with one attached, then the
> maintainer should strongly consider adding them to the package at the
> next convenient time.

Indeed no maintainer should be bothered with having his package install
a unit file, though two points.

A maintainer usually dislikes adding something contributed by a user
that he doesn't know about / can't verify . So letting systemd herd
picking unit files and committing them I think is reasonable. The
chance for screwing with a package by just adding the unit file are
close to zero even if not familiar with the package.

The other thing is those unit files really should come from upstream
and other distributions urge their developers to work with upstream [1]
Therefore I'd require an upstream bug for each unit that we add.


[1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files

[Rich Freeman]

On Fri, May 10, 2013 at 3:45 AM, Ralph Sennhauser <se...@gentoo.org> wrote:
> The other thing is those unit files really should come from upstream
> and other distributions urge their developers to work with upstream [1]
> Therefore I'd require an upstream bug for each unit that we add.

Makes sense, though I wouldn't necessarily make it a hard requirement.
Also, upstream units may not be usable as-is. They might reference
incorrect file locations (though I'd hope not for the most part), and
in particular dependency naming will always be a challenge.

Upstream rejection of a unit should certainly not lead to Gentoo
rejection of a unit, any more than their rejection of a script for
OpenRC should. Upstreams will likely be slow to embrace the
init-scripts-aren't-just-for-distros thing.

Rich

[Ralph Sennhauser]

On Fri, 10 May 2013 06:09:32 -0400
Rich Freeman <ri...@gentoo.org> wrote:

> On Fri, May 10, 2013 at 3:45 AM, Ralph Sennhauser <se...@gentoo.org>
> wrote:
> > The other thing is those unit files really should come from upstream
> > and other distributions urge their developers to work with upstream
> > [1] Therefore I'd require an upstream bug for each unit that we add.
>
> Makes sense, though I wouldn't necessarily make it a hard requirement.
> Also, upstream units may not be usable as-is. They might reference
> incorrect file locations (though I'd hope not for the most part), and
> in particular dependency naming will always be a challenge.

Adopting a package to distribution specifics is perfectly valid. But
here it's about adding functionality to a package that wasn't there
before. The usual reaction in such situations is to tell users to bug
upstream about it first.

>
> Upstream rejection of a unit should certainly not lead to Gentoo
> rejection of a unit, any more than their rejection of a script for
> OpenRC should. Upstreams will likely be slow to embrace the
> init-scripts-aren't-just-for-distros thing.
>
> Rich
>

If an upstream bug is filed and upstream says fuck off there is still a
bug report which would meet the requirement. Maybe some other distro
even filed the bug already for us.

[Rich Freeman]

On Sat, May 11, 2013 at 12:55 PM, Ralph Sennhauser <se...@gentoo.org> wrote:
> Adopting a package to distribution specifics is perfectly valid. But
> here it's about adding functionality to a package that wasn't there
> before. The usual reaction in such situations is to tell users to bug
> upstream about it first.

Adding an init.d script is hardly adding functionality - it is merely
making the package functional at all.

> If an upstream bug is filed and upstream says fuck off there is still a
> bug report which would meet the requirement. Maybe some other distro
> even filed the bug already for us.

I agree that it is a good practice, but it isn't a requirement. We
don't even require package maintainers to submit bugfix patches
upstream, let alone init scripts. Maintainers should certainly be
encouraged to do so, but it seems like we have enough trouble
following rules like "don't touch packages you don't maintain, fail to
test them, and end up breaking them."

Rich

[Luca Barbato]

On 05/10/2013 09:45 AM, Ralph Sennhauser wrote:
> [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files

What if openrc/upstart/runit devs start harassing upstream in the same way?

Strategically is great, but isn't exactly something nice to do.

Probably people caring about alternatives should start bothering
upstreams likewise and we'll see how it goes.

I'm sure that *everybody* would be delighted to provide those 4-5
different initscripts because one distribution or the other wants others
do the work for them...

I'm saying again that trying to get a good intermediate representation
and have a generator (eselect based maybe) provide the init-specific
file would be much better.

In the end initscripts are usually distribution dependent since they are
an integration step.

lu

[Michał Górny]

I'll start answering from the last point since it explains
the remaining answers. Sorry for the shuffle.

On Tue, 14 May 2013 10:41:27 +0200
Luca Barbato <lu_...@gentoo.org> wrote:

> On 05/10/2013 09:45 AM, Ralph Sennhauser wrote:
> > [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files
>

> In the end initscripts are usually distribution dependent since they are
> an integration step.

Integration? What kind of integration? The kind of integration which
results in various apps behaving differently depending on the patch set
used by distro?

The kind of integration which makes performing *simple* administrative
tasks completely distro-dependant? Seriously, I don't remember anymore how
to enable services on openrc. And I don't want to get back to the point
when approach a computer with Arch required me to find out how the necessary
tools are named there.

That said, Gentoo init.d scripts are an aberration. Either they
resemble poor hacks to change application behavior, provide additional
configuration or setup. Isn't init script supposed to *start*
an application?

When init scripts start to source additional code from external files,
poorly parse configuration files and reset databases, I believe we
reached the point of 'done seriously wrong'. And someone mentioned that
automatic restart of service is dangerous...

> What if openrc/upstart/runit devs start harassing upstream in the same way?
>
> Strategically is great, but isn't exactly something nice to do.
>
> Probably people caring about alternatives should start bothering
> upstreams likewise and we'll see how it goes.

Strategically? So we're now at war? Yes, I've noticed the few people
fancying a pile of hacks complaining about the 'so-wrong' systemd
breaking the unwritten rules of having a distro-specific pile of hacks
and trying to improve something for the sake of uniformity.

The point is that openrc/upstart/runit devs never cared enough. Maybe
they fancied their total control over init scripts or didn't feel
influential enough, I don't know.

Now that we have something that actually was designed with that point
in consideration, we have crybabies shouting 'but please use my init.d
instead! it's so much better because i used it'. The major difference
would be that systemd is something new, not just the pile of hacks that
has grown a lot of functionality over time.

> I'm sure that *everybody* would be delighted to provide those 4-5
> different initscripts because one distribution or the other wants others
> do the work for them...

Does it really? I more feel like it specifically doesn't want others to
touch their precious init scripts.

> I'm saying again that trying to get a good intermediate representation
> and have a generator (eselect based maybe) provide the init-specific
> file would be much better.

Did you see how systemd unit files look like? What kind of intermediate
representation do you want? I don't expect service descriptions to go
much simpler than this.

Of course, you could just mangle the names, change the format. Do that
for the sake of making things harder for others. Show how offended you
are by others not wanting your fancy init.d!

And eselect, of course. Another distro-specific pile of hacks which
doesn't do anything specific. I wonder if we will have to wait for
Fedora to replace it.

[Fabio Erculiani]

Are we realizing that in order to keep systemd out of our way, we're
currently writing and maintaining drop-in replacements for the
features that systemd is already providing in an actively maintained
state? openrc-settingsd was the first thing that we as Gentoo
developers (Pacho?) had to write in order to merge GNOME 3.6 into our
tree.

And now that GNOME 3.8 is out, the game starts over again: logind is a
hard requirement, logind is part of systemd, starting logind (which
replaces consolekit) is not that trivial as you may think (and is the
thing I started to work on anyway).

And if this wasn't enough, it means that if you want GNOME 3.8, you
need to get logind, which may or not may get included in our udev
ebuild and if it won't, it means that you will be forced to use
systemd as device manager if you want GNOME 3.8, which is believe it
or not, the thing that Ubuntu did.

The problem will only increase in size as the clock moves.

And (and!) how does all this fit together with eudev? If the idea is
to either put logind in udev (thus, not creating a separate logind
ebuild), it means that eudev is already a dead end for GNOME users,
unless the eudev team is going to provide logind as well.

I don't want to start a flamewar here, I was the one who called
Lennart software lennartware, but science is science, and a reality
check had to be done: at some near point in the future, our users will
be forced to replace udev/eudev with systemd. Like it. Or not.

While I successfully use both openrc and systemd, I _do_ think that
(and expect to see) more and more users (and developers) will be
switching to systemd.
Is there anything we can do? Besides "being prepared", I don't think so.
Do we control upstreams? No, sorry.

So what do we want to do then? Isolate from the rest of the world?
(It's not a sarcastic question). I hope that everybody does their own
reality check.

--
Fabio Erculiani

[Pacho Ramos]

El mié, 15-05-2013 a las 15:41 +0200, Fabio Erculiani escribió:
> Are we realizing that in order to keep systemd out of our way, we're
> currently writing and maintaining drop-in replacements for the
> features that systemd is already providing in an actively maintained
> state? openrc-settingsd was the first thing that we as Gentoo
> developers (Pacho?) had to write in order to merge GNOME 3.6 into our
> tree.

Tetromino is the expert in openrc-settingsd I think, I don't know much
about it :S

>
> And now that GNOME 3.8 is out, the game starts over again: logind is a
> hard requirement, logind is part of systemd, starting logind (which
> replaces consolekit) is not that trivial as you may think (and is the
> thing I started to work on anyway).
>
> And if this wasn't enough, it means that if you want GNOME 3.8, you
> need to get logind, which may or not may get included in our udev
> ebuild and if it won't, it means that you will be forced to use
> systemd as device manager if you want GNOME 3.8, which is believe it
> or not, the thing that Ubuntu did.

Ubuntu is installing systemd to get their "udev" and "logind"... but
still using upstart (with gnome 3.8 packages)

But, well, I think the easiest solution would be to move to systemd and
run the parts we need from it even still booting with openrc

[Rich Freeman]

On Wed, May 15, 2013 at 9:41 AM, Fabio Erculiani <lx...@gentoo.org> wrote:
> And (and!) how does all this fit together with eudev? If the idea is
> to either put logind in udev (thus, not creating a separate logind
> ebuild), it means that eudev is already a dead end for GNOME users,
> unless the eudev team is going to provide logind as well.

I picked this paragraph to quote, but this is more of an overall
response to your email.

Gentoo is about choice, but that doesn't mean that every developer has
to support every possible choice on every package.

Eudev not working with gnome is not a reason to hold back either
project. Not every option in Gentoo has to be compatible with every
other option.

Eudev is welcome to stay even if its developers are its only users.

I do agree in general that systemd seems pretty likely to take over,
but that doesn't mean that those who aren't running big desktop
environments can't make use of the alternatives, or that providing
alternatives is bad. I doubt you'll ever get Gnome 3.8 running on
Prefix either. :)

Rich

[Ben de Groot]

On 15 May 2013 21:41, Fabio Erculiani <lx...@gentoo.org> wrote:
> Are we realizing that in order to keep systemd out of our way, we're
> currently writing and maintaining drop-in replacements for the
> features that systemd is already providing in an actively maintained
> state? openrc-settingsd was the first thing that we as Gentoo
> developers (Pacho?) had to write in order to merge GNOME 3.6 into our
> tree.

It's well known that Gnome is part and parcel of the whole vertical
integration circus.

> And (and!) how does all this fit together with eudev? If the idea is
> to either put logind in udev (thus, not creating a separate logind
> ebuild), it means that eudev is already a dead end for GNOME users,
> unless the eudev team is going to provide logind as well.

I'm not sure what the eudev team is planning, but it's been working
well so far for me. And since I don't use Gnome, it's not an issue as
long as other desktop environments are not making the same mistakes.

> I don't want to start a flamewar here, I was the one who called
> Lennart software lennartware, but science is science, and a reality
> check had to be done: at some near point in the future, our users will
> be forced to replace udev/eudev with systemd. Like it. Or not.

This isn't science. And unless you use Gnome, I don't see why we would
be forced to use systemd. KDE, Xfce, LXDE and Razor-qt are still happy
to support non-systemd operating systems. The way I see it is that
Gnome is making itself more of a non-option on Gentoo, Slackware and
BSD systems.

> While I successfully use both openrc and systemd, I _do_ think that
> (and expect to see) more and more users (and developers) will be
> switching to systemd.
> Is there anything we can do? Besides "being prepared", I don't think so.
> Do we control upstreams? No, sorry.

We don't control upstreams, but we still have choices. At this point I
only see Gnome and udev upstreams who are forcing their users to use
systemd. (There may be other projects too that I'm not aware of.)

> So what do we want to do then? Isolate from the rest of the world?
> (It's not a sarcastic question). I hope that everybody does their own
> reality check.

We say that Gentoo stands for choice. That is why we should resist
allowing systemd (and Gnome) to take those choices away with their
mistaken idea of vertical integration. We do have other options.

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/05/13 10:16 AM, Ben de Groot wrote:
> On 15 May 2013 21:41, Fabio Erculiani <lx...@gentoo.org> wrote:
>> And (and!) how does all this fit together with eudev? If the idea
>> is to either put logind in udev (thus, not creating a separate
>> logind ebuild), it means that eudev is already a dead end for
>> GNOME users, unless the eudev team is going to provide logind as
>> well.
>
> I'm not sure what the eudev team is planning, but it's been
> working well so far for me. And since I don't use Gnome, it's not
> an issue as long as other desktop environments are not making the
> same mistakes.
>

We don't know what we're planning either -- this is the first that I
heard sys-fs/udev maintainers are considering bundling logind. Gut
reaction is that eudev isn't going to do this, but the eudev team of
course need to have an actual discussion and decision on it as a project.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGTovIACgkQ2ugaI38ACPDVZQD/dJUbQ9oMl9BAiMuM+SwtETad
PkhRLDVaBEN2FqwXFQIA/3wPouBLnzHT1p1uNL5zfcc8Hf/RgFoKKbaZ/deZM6s2
=xukU
-----END PGP SIGNATURE-----

[Luca Barbato]

On 05/15/2013 03:41 PM, Fabio Erculiani wrote:
> Are we realizing that in order to keep systemd out of our way, we're
> currently writing and maintaining drop-in replacements for the
> features that systemd is already providing in an actively maintained
> state? openrc-settingsd was the first thing that we as Gentoo
> developers (Pacho?) had to write in order to merge GNOME 3.6 into our
> tree.

> And now that GNOME 3.8 is out, the game starts over again: logind is a
> hard requirement, logind is part of systemd, starting logind (which
> replaces consolekit) is not that trivial as you may think (and is the
> thing I started to work on anyway).

> And if this wasn't enough, it means that if you want GNOME 3.8, you
> need to get logind, which may or not may get included in our udev
> ebuild and if it won't, it means that you will be forced to use
> systemd as device manager if you want GNOME 3.8, which is believe it
> or not, the thing that Ubuntu did.

> The problem will only increase in size as the clock moves.

And given that the end-plan according to the guys is to kill the
distributions shall we just close Gentoo now?

> And (and!) how does all this fit together with eudev? If the idea is
> to either put logind in udev (thus, not creating a separate logind
> ebuild), it means that eudev is already a dead end for GNOME users,
> unless the eudev team is going to provide logind as well.

Are there specifications regarding logind ? Is that so incredibly
terrible write and maintain 1k loc?

> I don't want to start a flamewar here, I was the one who called
> Lennart software lennartware, but science is science, and a reality
> check had to be done: at some near point in the future, our users will
> be forced to replace udev/eudev with systemd. Like it. Or not.

Science is science, systemd doesn't work with anything but linux, Gentoo
in theory should care about not-linux.

> While I successfully use both openrc and systemd, I _do_ think that
> (and expect to see) more and more users (and developers) will be
> switching to systemd.

Surely sysadmins will be delighted about that.

> Is there anything we can do? Besides "being prepared", I don't think so.
> Do we control upstreams? No, sorry.

I'm upstream for some stuff, vlc was already really close to force-kill
pulseaudio because of some cute problems, the thing got otherwise fixed.

Upstream does what is most sensible for the users, usually.

Freebsd, openbsd and some other operating systems are still there, they
have their reasons and usually work better in those fields than other,
I'm sure some people would wish to kill them, not going to happen
anytime soon.

> So what do we want to do then? Isolate from the rest of the world?

The world is bigger than that and we were making bridges around, *why*
severing them because somebody else decided for you?

> (It's not a sarcastic question). I hope that everybody does their own
> reality check.

Did mine, other experienced the hard way what I said many times.

Gnome doesn't seem a good reason to leave in the cold people that do not
even care about it.

lu

[Luca Barbato]

On 05/15/2013 05:03 PM, Luca Barbato wrote:
> On 05/15/2013 03:41 PM, Fabio Erculiani wrote:
>> Are we realizing that in order to keep systemd out of our way, we're
>> currently writing and maintaining drop-in replacements for the
>> features that systemd is already providing in an actively maintained
>> state? openrc-settingsd was the first thing that we as Gentoo
>> developers (Pacho?) had to write in order to merge GNOME 3.6 into our
>> tree.

To make it even clearer.

In order to support a good amount of users out there that do not care
about gnome and cannot use systemd we can see and bake alternatives that
are compatible enough.

Those that can't use systemd:

- those not using the latest glibc (and maybe uclibc)
- those not using a recent linux kernel
- not sure about cgroups-users, the lxc vs systemd problem should be
solved I hope

That's what I'm aware of.

lu

[Tom Wijsman]

On Wed, 15 May 2013 17:10:03 +0200
Luca Barbato <lu_...@gentoo.org> wrote:

> - those not using the latest glibc (and maybe uclibc)

Did you test this? Are there more specific details regarding this?
Which version don't work? Is it known why?

> - those not using a recent linux kernel

It works on all gentoo-sources kernels (I test them), is 2.6 meant with
not recent or are these kernels even older? Those kind of people likely
don't care much about upgrading anyway and thus don't need systemd, but
they rather enjoy to have a system full of security issues.

--
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address : Tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D

[Tom Wijsman]

On Wed, 15 May 2013 17:03:13 +0200
Luca Barbato <lu_...@gentoo.org> wrote:

> On 05/15/2013 03:41 PM, Fabio Erculiani wrote:

> > ... GNOME ...

>
> And given that the end-plan according to the guys is to kill the
> distributions shall we just close Gentoo now?

Let's not exaggerate things, there are a ton of other DEs out there;
are all of them starting to depend on systemd specific features?

> > And (and!) how does all this fit together with eudev? If the idea is
> > to either put logind in udev (thus, not creating a separate logind
> > ebuild), it means that eudev is already a dead end for GNOME users,
> > unless the eudev team is going to provide logind as well.
>

> Is that so incredibly terrible write and maintain 1k loc?

Whether or not it is terrible, it is a time sink; is it worth doing it?

> > I don't want to start a flamewar here, I was the one who called
> > Lennart software lennartware, but science is science, and a reality
> > check had to be done: at some near point in the future, our users
> > will be forced to replace udev/eudev with systemd. Like it. Or not.
>
> Science is science, systemd doesn't work with anything but linux,
> Gentoo in theory should care about not-linux.

Indeed, the goal here is solely to make "systemd more accessible"; we
shouldn't pursue it to be the main init system or force it upon users,
unless there are indicators in the future that it became better (eg.
supports BSD, ...) for everyone.

Whether upstreams will force users remains to be a question to me, this
thread indicates a view from the GNOME users side; but that does not
target the wide audience that uses other DEs.

> > Is there anything we can do? Besides "being prepared", I don't
> > think so. Do we control upstreams? No, sorry.
>
> I'm upstream for some stuff, vlc was already really close to
> force-kill pulseaudio because of some cute problems, the thing got
> otherwise fixed.

Patches are still an option, and if patches become to tedious there
is the possibility to fork in the worst caste; if there aren't either
of those, we probably don't care enough to provide that piece of
software to our users. There's a moment one has to stop caring about
certain broken / incompatible pieces of software and throw them out.

> Freebsd, openbsd and some other operating systems are still there,
> they have their reasons and usually work better in those fields than
> other, I'm sure some people would wish to kill them, not going to
> happen anytime soon.

It's better to be neutral than to pursue something you can't accomplish.

> > So what do we want to do then? Isolate from the rest of the world?
>
> The world is bigger than that and we were making bridges around, *why*
> severing them because somebody else decided for you?

Indeed, I'd rather embrace than isolate; if something is useful for a
large share of users, isolating us from it won't make anybody happy.

> > (It's not a sarcastic question). I hope that everybody does their
> > own reality check.
>
> Did mine, other experienced the hard way what I said many times.
>
> Gnome doesn't seem a good reason to leave in the cold people that do
> not even care about it.

Used GNOME for months, then with 3.6 - 3.8 it started to break on me;
it didn't work on either OpenRC or systemd. While I was a happy user at
first, recent events made me lose interest in it; I think a discussion
regarding init systems and similar software shouldn't be focused on a
single DE, so I too am not sure why focus is laid on GNOME here...

[Rich Freeman]

On Wed, May 15, 2013 at 12:59 PM, Tom Wijsman <Tom...@gentoo.org> wrote:
> On Wed, 15 May 2013 17:10:03 +0200
> Luca Barbato <lu_...@gentoo.org> wrote:
>
>> - those not using the latest glibc (and maybe uclibc)
>
> Did you test this? Are there more specific details regarding this?
> Which version don't work? Is it known why?
>
>> - those not using a recent linux kernel
>
> It works on all gentoo-sources kernels (I test them), is 2.6 meant with
> not recent or are these kernels even older? Those kind of people likely
> don't care much about upgrading anyway and thus don't need systemd, but
> they rather enjoy to have a system full of security issues.

Don't take it personally or as an attack on systemd. I think he was
just pointing out that there are many use cases where systemd may not
be appropriate.

I'm sure if you pulled a glibc from 10 years ago there would be a
pretty good chance that systemd wouldn't work, but openrc is mainly
based on shell (not even bash), so it would be pretty likely to work.
Likewise if you picked a kernel from a few years ago systemd with all
its use of cgroups and such probably wouldn't work, while openrc is
simpler. Certainly if you picked a FreeBSD kernel systemd will not
work. (Keep in mind the set of systems not using a recent linux
kernel includes all systems that don't run linux at all.)

In any case, there really isn't any "decision" to make here. As long
as devs want to support openrc it will be supported. Likewise with
eudev. As long as devs want to support systemd and udev those will be
options as well. The beauty of Gentoo is that more than any distro it
maximizes the options for our users. The changes in Gnome may
eliminate Gnome+openrc as a practical option, and when those teams
stop supporting the combo then users will have to make a choice to not
use one or the other. Gentoo is about choice, but that doesn't mean
that we have to offer EVERY possible choice. If somebody wants to
support my hp48 calculator as a Gentoo arch that would be great, but
that doesn't mean that I can start hassling teams to do the work for
me.

Gentoo is about working TOGETHER to provide choices, not about telling
others to make choices work for you.

Rich

[Tom Wijsman]

On Wed, 15 May 2013 13:25:11 -0400
Rich Freeman <ri...@gentoo.org> wrote:

> On Wed, May 15, 2013 at 12:59 PM, Tom Wijsman <Tom...@gentoo.org>
> wrote:
> Don't take it personally or as an attack on systemd. I think he was
> just pointing out that there are many use cases where systemd may not
> be appropriate.

In discussions, I try to not root for object X or Y but be constructive.

> I'm sure if you pulled a glibc from 10 years ago there would be a
> pretty good chance that systemd wouldn't work, but openrc is mainly
> based on shell (not even bash), so it would be pretty likely to work.

That is, if OpenRC is POSIX.1-2001 compatible; it doesn't use any APIs
or programs developed in the last 10 years, it doesn't depend on a
certain way a certain feature works that has changed in last 10 years.

Agreed though, shell changes less often than glibc; but that's merely
based on time, I can imagine in some point in the future there may be
no need for further changes in glibc the same way POSIX stopped
changing years ago; or in other words, it got standardized to be solid.

Going back from those details to OpenRC and systemd, one could say that
one tool depends on old and solid standards while the other depends on
new and developing technologies; there are reasons enough to choose for
either. Some things are better done by A, others by B.

That's not what I'm after, I want to know when either A or B doesn't
work; this is a matter of 1) trying to make it work for our users and 2)
documenting it to our users in which occasions it doesn't work.

Though, I went to take a look, if I were to trust the systemd ebuild it
seems that it doesn't work with glibc versions prior to May 2009 (2.10)
so I think we're in a quite good standing here; the amount of users
that don't upgrade for four years that need systemd is likely minor,
hence we don't need to document this and this doesn't form a problem.

> Likewise if you picked a kernel from a few years ago systemd with all
> its use of cgroups and such probably wouldn't work, while openrc is
> simpler. Certainly if you picked a FreeBSD kernel systemd will not
> work. (Keep in mind the set of systems not using a recent linux
> kernel includes all systems that don't run linux at all.)

I don't think the goal of making systemd more accessible has anything
to do with people that don't upgrade for a few years; it doesn't stand
in their way and given that it is out of the Portage tree we likely
don't support these kind of practices anymore. Support is a big word
and doesn't mean we don't try to help them if they have a solid case,
but I can't see someone with <2006 hardware wanting to run GNOME 3.8.

> In any case, there really isn't any "decision" to make here.

Then for what purpose is this discussion still going on?

> As long as devs want to support openrc it will be supported.
> Likewise with eudev. As long as devs want to support systemd and
> udev those will be options as well. The beauty of Gentoo is that more
> than any distro it maximizes the options for our users. The changes
> in Gnome may eliminate Gnome+openrc as a practical option, and when
> those teams stop supporting the combo then users will have to make a
> choice to not use one or the other. Gentoo is about choice, but that
> doesn't mean that we have to offer EVERY possible choice. If
> somebody wants to support my hp48 calculator as a Gentoo arch that

> would be great, but that doesn't mean that I can sta hassling teams

> to do the work for me.
>
> Gentoo is about working TOGETHER to provide choices, not about telling
> others to make choices work for you.

That's what I'm after, I have send a very similar mail two months ago.

[Rich Freeman]

On Wed, May 15, 2013 at 2:11 PM, Tom Wijsman <Tom...@gentoo.org> wrote:
> On Wed, 15 May 2013 13:25:11 -0400
> Rich Freeman <ri...@gentoo.org> wrote:
>
>> In any case, there really isn't any "decision" to make here.
>
> Then for what purpose is this discussion still going on?
>

No comment on that...

Maybe another way of saying things is that really the onus is on those
who want others to change their behavior to explain why they should
change. So, if you're seeking a change in behavior be up-front about
what change you want. If you're not seeking a change in behavior,
then there really isn't much point in going on unless it is to resist
a proposed change.

Personally I think a reasonable balance is:

1. Maintainers do not have to take initiative to create systemd
units. (status quo)
2. Maintainers should accept contributed units from the community,
even if they can't personally test them. This can be done at their
convenience. (slight addition in work for maintainers)
3. Maintainers can ask users to contribute units upstream if not
already done. I don't think this should be a hard requirement (ie
accepting a non-upstreamed unit is not a QA violation). If upstream
makes this difficult this should not be an excuse for marking bugs
invalid. The goal is to work with upstream, not harass them. (some
more work for bug submitters and maintainers).

Bottom line - maintainers don't have to go out of their way to support
systemd, but they should be friendly facilitators when others are
willing to do the work. This is no different from accepting desktop
entries and such even if you don't use a Freedesktop-compatible
environment.

Rich

[Pacho Ramos]

El mié, 15-05-2013 a las 15:02 -0400, Rich Freeman escribió:
[...]

+1

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/05/13 17:10, Luca Barbato wrote:
> Those that can't use systemd: - those not using a recent linux
> kernel
And let's not forget those who aren't using Linux at all.
- --
Alexander
alex...@plaimi.net
http://plaimi.net/~alexander

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlGT9nUACgkQRtClrXBQc7UHiQD/R07lH+0F6ZARoODe2efrMVii
w5Ok3kTjChpjkvLKjt8BAJIh8Rt+wmljyfT+yjj3WY2BfFWx4Vxkt2lom6V4G0A/
=NqLn
-----END PGP SIGNATURE-----

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 15 May 2013 22:56:21 +0200
Alexander Berntsen <alex...@plaimi.net> wrote:
> On 15/05/13 17:10, Luca Barbato wrote:
> > Those that can't use systemd: - those not using a recent linux
> > kernel
>
> And let's not forget those who aren't using Linux at all.

Why not?

- --
Ciaran McCreesh

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlGT98MACgkQ96zL6DUtXhHnPACgqIhmnyvutdvIw0ijl4ralYyz
cwMAn24EP4lpA/jHAdxAv6lx2e74qxy6
=68cT
-----END PGP SIGNATURE-----

[walt...@waltdnes.org]

On Wed, May 15, 2013 at 03:41:31PM +0200, Fabio Erculiani wrote

> Are we realizing that in order to keep systemd out of our way, we're
> currently writing and maintaining drop-in replacements for the
> features that systemd is already providing in an actively maintained
> state? openrc-settingsd was the first thing that we as Gentoo
> developers (Pacho?) had to write in order to merge GNOME 3.6 into our
> tree.

So Redhat, who are heavily into GNOME
( http://fedoraproject.org/wiki/Red_Hat_contributions#GNOME_developers )
decided to make GNOME depend on other Redhat-developed software (systemd
and pulseadio). Well... like... dohhhh...

Question... when Sun made OpenOffice depend on Java (also a Sun
product) did Gentoo developers run around suggesting that Java be made a
part of the core Gentoo base system? I don't think so. If a user wants
to run GNOME badly enough, he'll switch to systemd. I don't see why the
rest of us (i.e. non-users of GNOME) should have to follow along and
reconfigure our systems. This is a case of the tail wagging the dog.

> So what do we want to do then? Isolate from the rest of the world?
> (It's not a sarcastic question). I hope that everybody does their
> own reality check.

You are effectively calling not-using-GNOME isolationist. Let's just
say I disagree with you on that. BTW, see my sig.

--
Walter Dnes <walt...@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[Rich Freeman]

On Wed, May 15, 2013 at 2:18 PM, <walt...@waltdnes.org> wrote:
> Question... when Sun made OpenOffice depend on Java (also a Sun
> product) did Gentoo developers run around suggesting that Java be made a
> part of the core Gentoo base system? I don't think so. If a user wants
> to run GNOME badly enough, he'll switch to systemd. I don't see why the
> rest of us (i.e. non-users of GNOME) should have to follow along and
> reconfigure our systems. This is a case of the tail wagging the dog.

It will probably be more than a decade before anybody is FORCED to run
systemd on Gentoo. You don't even have to run udev on Gentoo.

It will probably be years before the default even changes, assuming
the trajectory of systemd remains as it seems to be.

I think people are really getting carried away here. I believe the
udev team generally wants to follow upstream udev, and there is eudev
and busybox mdev for those who don't want that. No distro provides so
many ways of avoiding systemd. I don't see that changing anytime
soon.

This thread just started out asking maintainers to commit unit files
when asked, that's all. Anybody who doesn't want them can mask them.
If anybody feels eudev/openrc/whatever isn't progressing enough they
can contribute improvements to these packages, or pay somebody else to
do it for them. Developers work on what they want to work on. If no
devs can be bothered with systemd then it will die on the vine, and if
no developers choose to work on openrc the same will happen there.
Either is unlikely, though the "market share" of either is likely to
change over time.

Rich

[Matthew Thode]

On 05/15/13 16:01, Ciaran McCreesh wrote:
> On Wed, 15 May 2013 22:56:21 +0200
> Alexander Berntsen <alex...@plaimi.net> wrote:
>> On 15/05/13 17:10, Luca Barbato wrote:
>>> Those that can't use systemd: - those not using a recent linux
>>> kernel
>
>> And let's not forget those who aren't using Linux at all.
>
> Why not?
>
>

Troll mode engaged?
--
-- Matthew Thode (prometheanfire)