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

[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

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

[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!

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

[Fabio Erculiani]

On Wed, May 1, 2013 at 12:50 PM, Pacho Ramos <pacho@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

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

[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

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

[Michał Górny]

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

On Wed, 01 May 2013 12:50:42 +0200
Pacho Ramos <pacho@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[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 ;-)

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

[Fabio Erculiani]

On Wed, May 1, 2013 at 2:54 PM, Steven J. Long
<slong@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

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

[Matthew Thode]

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

On 05/01/13 05:04, 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.
> 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,
> 
Isn't there a tracker (and if not, why have you not created one yet :P )

-- 
-- Matthew Thode (prometheanfire)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Fabio Erculiani]

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

-- 
Fabio Erculiani

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

[Rich Freeman]

On Wed, May 1, 2013 at 6:04 AM, Fabio Erculiani <lxnay@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

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

[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
> <slong@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.

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

["Paweł Hajdan, Jr."]

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

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ł



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

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

[Michał Górny]

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

On Wed, 01 May 2013 12:52:09 -0700
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> 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.

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...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Fabio Erculiani]

On Wed, May 1, 2013 at 9:52 PM, "Paweł Hajdan, Jr."
<phajdan.jr@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

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

[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

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

[Matt Turner]

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

Amazing. I came to the exact opposite conclusion.

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

[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

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

[Alex Xu]

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

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[William Hubbs]

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

On Wed, May 01, 2013 at 03:13:54PM +0200, Pacho Ramos wrote:
> 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

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[William Hubbs]

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

On Wed, May 01, 2013 at 11:14:28PM +0200, Fabio Erculiani wrote:
> On Wed, May 1, 2013 at 9:52 PM, "Paweł Hajdan, Jr."
> <phajdan.jr@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.

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Kent Fredric]

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

On 2 May 2013 15:18, William Hubbs <williamh@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

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

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

[Fabio Erculiani]

On Thu, May 2, 2013 at 5:26 AM, Kent Fredric <kentfredric@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

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

[William Hubbs]

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

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mike Gilbert]

On Thu, May 2, 2013 at 2:05 PM, William Hubbs <williamh@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.

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

[Fabio Erculiani]

On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert <floppym@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

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

[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

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

[Rich Freeman]

On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani <lxnay@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

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

[Mike Gilbert]

On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani <lxnay@gentoo.org> wrote:
> On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert <floppym@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.

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

[William Hubbs]

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

On Thu, May 02, 2013 at 03:39:25PM -0400, Mike Gilbert wrote:
> On Thu, May 2, 2013 at 3:01 PM, Fabio Erculiani <lxnay@gentoo.org> wrote:
> > On Thu, May 2, 2013 at 8:13 PM, Mike Gilbert <floppym@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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Kent Fredric]

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

On 3 May 2013 07:01, Fabio Erculiani <lxnay@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

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

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

[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 <williamh@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.

-- 
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

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

[William Hubbs]

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

On Fri, May 03, 2013 at 08:27:36AM +1200, Kent Fredric wrote:
> On 3 May 2013 07:01, Fabio Erculiani <lxnay@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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[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).


Best regards,
Chí-Thanh Christopher Nguyễn

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

[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

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

[Rich Freeman]

On Sat, May 4, 2013 at 6:42 AM, Luca Barbato <lu_zero@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

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

[Fabio Erculiani]

On Sat, May 4, 2013 at 12:42 PM, Luca Barbato <lu_zero@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...?

>
>> 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
>
>



-- 
Fabio Erculiani

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

[Fabio Erculiani]

On Sat, May 4, 2013 at 3:05 PM, Fabio Erculiani <lxnay@gentoo.org> wrote:
>
> 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?
>

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

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

[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 :/

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

[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

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

[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

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

[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_zero@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.

-- 
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

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

[Fabio Erculiani]

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

-- 
Fabio Erculiani

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

[Ben de Groot]

On 1 May 2013 18:04, Fabio Erculiani <lxnay@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

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

[Fabio Erculiani]

On Wed, May 8, 2013 at 5:26 PM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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

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

[Chí-Thanh Christopher Nguyễn]

Ben de Groot schrieb:
> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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).


Best regards,
Chí-Thanh Christopher Nguyễn

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

[Ben de Groot]

On 8 May 2013 23:39, Fabio Erculiani <lxnay@gentoo.org> wrote:
> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot <yngwin@gentoo.org> wrote:
>> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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.

--
Cheers,

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

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

[Fabio Erculiani]

On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Ben de Groot schrieb:
>> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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

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

[Michael Mol]

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

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 <lxnay@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)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Fabio Erculiani]

On Wed, May 8, 2013 at 5:49 PM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 8 May 2013 23:39, Fabio Erculiani <lxnay@gentoo.org> wrote:
>> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot <yngwin@gentoo.org> wrote:
>>> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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

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

[Mike Gilbert]

On Wed, May 8, 2013 at 11:49 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 8 May 2013 23:39, Fabio Erculiani <lxnay@gentoo.org> wrote:
>> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot <yngwin@gentoo.org> wrote:
>>> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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.

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

[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.


Best regards,
Chí-Thanh Christopher Nguyễn

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

[Mike Gilbert]

On Wed, May 8, 2013 at 12:06 PM, Chí-Thanh Christopher Nguyễn
<chithanh@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/*". 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.

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

[Ben de Groot]

On 8 May 2013 23:49, Fabio Erculiani <lxnay@gentoo.org> wrote:
> On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn
> <chithanh@gentoo.org> wrote:
>> Ben de Groot schrieb:
>>> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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.

--
Cheers,

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

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

[Ian Stakenvicius]

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

On 08/05/13 11:49 AM, Ben de Groot wrote:
> On 8 May 2013 23:39, Fabio Erculiani <lxnay@gentoo.org> wrote:
>> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot <yngwin@gentoo.org>
>> wrote:
>>> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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 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-----

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

[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 <yngwin@gentoo.org>
> wrote:
>> On 8 May 2013 23:39, Fabio Erculiani <lxnay@gentoo.org> wrote:
>>> On Wed, May 8, 2013 at 5:26 PM, Ben de Groot
>>> <yngwin@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-----

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

[Chí-Thanh Christopher Nguyễn]

Mike Gilbert schrieb:
> On Wed, May 8, 2013 at 12:06 PM, Chí-Thanh Christopher Nguyễn
> <chithanh@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.


Best regards,
Chí-Thanh Christopher Nguyễn

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

[Rich Freeman]

On Wed, May 8, 2013 at 11:26 AM, Ben de Groot <yngwin@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

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

[Arun Raghavan]

On 8 May 2013 21:51, Ben de Groot <yngwin@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

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

[Michał Górny]

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

On Thu, 9 May 2013 00:21:53 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 8 May 2013 23:49, Fabio Erculiani <lxnay@gentoo.org> wrote:
> > On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn
> > <chithanh@gentoo.org> wrote:
> >> Ben de Groot schrieb:
> >>> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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.

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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Michał Górny]

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

On Wed, 8 May 2013 23:26:57 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Michael Mol]

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

On 05/08/2013 01:08 PM, Michał Górny wrote:
> On Wed, 8 May 2013 23:26:57 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
> 
>> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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...

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Michał Górny]

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

On Wed, 08 May 2013 13:18:57 -0400
Michael Mol <mikemol@gmail.com> wrote:

> On 05/08/2013 01:08 PM, Michał Górny wrote:
> > On Wed, 8 May 2013 23:26:57 +0800
> > Ben de Groot <yngwin@gentoo.org> wrote:
> > 
> >> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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...
> 
> 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.

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

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Rich Freeman]

On Wed, May 8, 2013 at 1:18 PM, Michael Mol <mikemol@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

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

[William Hubbs]

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

On Wed, May 08, 2013 at 11:49:18PM +0800, Ben de Groot wrote:
> On 8 May 2013 23:39, Fabio Erculiani <lxnay@gentoo.org> wrote:
> > On Wed, May 8, 2013 at 5:26 PM, Ben de Groot <yngwin@gentoo.org> wrote:
> >> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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.

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[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

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

[William Hubbs]

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

On Thu, May 09, 2013 at 12:21:53AM +0800, Ben de Groot wrote:
> On 8 May 2013 23:49, Fabio Erculiani <lxnay@gentoo.org> wrote:
> > On Wed, May 8, 2013 at 5:39 PM, Chí-Thanh Christopher Nguyễn
> > <chithanh@gentoo.org> wrote:
> >> Ben de Groot schrieb:
> >>> On 1 May 2013 18:04, Fabio Erculiani <lxnay@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.

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Jeroen Roovers]

On Wed, 8 May 2013 21:48:36 -0400
"Walter Dnes" <waltdnes@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

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

[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.

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

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

[Canek Peláez Valdés]

On Wed, May 8, 2013 at 9:18 PM, Walter Dnes <waltdnes@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

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

[Anthony G. Basile]

On 05/08/2013 10:01 PM, Jeroen Roovers wrote:
> On Wed, 8 May 2013 21:48:36 -0400
> "Walter Dnes" <waltdnes@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
>

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

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

[Rich Freeman]

On Wed, May 8, 2013 at 10:18 PM, Walter Dnes <waltdnes@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

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

[Michał Górny]

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

On Thu, 09 May 2013 05:56:42 -0400
"Anthony G. Basile" <basile@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" <waltdnes@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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Rich Freeman]

On Thu, May 9, 2013 at 12:44 PM, Michał Górny <mgorny@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

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

[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 ;))

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

[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 ;-)

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

[Ralph Sennhauser]

On Wed, 8 May 2013 13:37:51 -0400
Rich Freeman <rich0@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

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

[Rich Freeman]

On Fri, May 10, 2013 at 3:45 AM, Ralph Sennhauser <sera@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

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

[Ralph Sennhauser]

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

> On Fri, May 10, 2013 at 3:45 AM, Ralph Sennhauser <sera@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.

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

[Rich Freeman]

On Sat, May 11, 2013 at 12:55 PM, Ralph Sennhauser <sera@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

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

[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

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

[Michał Górny]

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

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_zero@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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[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

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

[Rich Freeman]

On Wed, May 15, 2013 at 9:41 AM, Fabio Erculiani <lxnay@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

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

[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

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

[Ben de Groot]

On 15 May 2013 21:41, Fabio Erculiani <lxnay@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.

--
Cheers,

Ben | yngwin
Gentoo developer

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

[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 <lxnay@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-----

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

[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

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

[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

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

[Tom Wijsman]

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

On Wed, 15 May 2013 17:10:03 +0200
Luca Barbato <lu_zero@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Rich Freeman]

On Wed, May 15, 2013 at 12:59 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Wed, 15 May 2013 17:10:03 +0200
> Luca Barbato <lu_zero@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

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

[Tom Wijsman]

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

On Wed, 15 May 2013 17:03:13 +0200
Luca Barbato <lu_zero@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...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Tom Wijsman]

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

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

> On Wed, May 15, 2013 at 12:59 PM, Tom Wijsman <TomWij@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.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[waltdnes]

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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Rich Freeman]

On Wed, May 15, 2013 at 2:11 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Wed, 15 May 2013 13:25:11 -0400
> Rich Freeman <rich0@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

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

[Pacho Ramos]

El mié, 15-05-2013 a las 15:02 -0400, Rich Freeman escribió:
[...]
> 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
> 

+1

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

[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
alexander@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-----

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

[Ciaran McCreesh]

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

On Wed, 15 May 2013 22:56:21 +0200
Alexander Berntsen <alexander@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-----

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

[waltdnes]

On Wed, May 15, 2013 at 06:38:14PM -0400, Rich Freeman wrote

> 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.

  I was replyiny to a poster who said...

> at some near point in the future, our users will be forced to replace
> udev/eudev with systemd. Like it. Or not.

  You mentioned that it will be years before it happens.  I realize
that this borders on the political, but if nobody objects *NOW*, in a
couple of years it'll happen.  And the developers will say "but nobody
objected".  You're right that the process takes time.  It's precisely
because of that that unhappy users need to make their feelings known
now before it's too late.

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

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

[Rich Freeman]

On Wed, May 15, 2013 at 2:18 PM,  <waltdnes@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

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

[Matthew Thode]

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

On 05/15/13 16:01, Ciaran McCreesh wrote:
> On Wed, 15 May 2013 22:56:21 +0200
> Alexander Berntsen <alexander@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)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[William Hubbs]

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

On Wed, May 15, 2013 at 10:16:01PM +0800, Ben de Groot wrote:
> 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.)

Udev doesn't force anything. In fact upstream makes it
clear that udev can be run without systemd.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[William Hubbs]

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

On Wed, May 15, 2013 at 10:56:21PM +0200, Alexander Berntsen wrote:
> -----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.

I'm not really sure how relevant this is, because we can set up
different default init systems based on the operating system in our tree
easily enough.

If we decide in the future to make the default init system on linux
systemd, it is simple enough to make it OpenRC or whatever else on *bsd.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[William Hubbs]

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

On Wed, May 15, 2013 at 02:18:13PM -0400, waltdnes@waltdnes.org wrote:
> 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.
 
 I don't interpret what he is saying that way. I think what he is
 talking about is that we are trying to get teams to support non-systemd
 setups when upstreams do not, like with gnome.

 Gnome now has a hard dependency on systemd (for gnome newer than 3.8).
 Some folks want to use gnome without systemd and are putting that under
 the gentoo is about choice banner and want us to support them.

> > 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.

See above.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Matthew Thode]

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

On 05/15/13 19:27, William Hubbs wrote:
> On Wed, May 15, 2013 at 10:16:01PM +0800, Ben de Groot wrote:
>> 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.)
> 
> Udev doesn't force anything. In fact upstream makes it
> clear that udev can be run without systemd.
> 
> William
> 
so then we should decouple logind from udev downstream (packaging) :D

-- 
-- Matthew Thode (prometheanfire)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Matthew Thode]

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

On 05/15/13 20:20, William Hubbs wrote:
> On Wed, May 15, 2013 at 02:18:13PM -0400, waltdnes@waltdnes.org wrote:
>> 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.
>  
>  I don't interpret what he is saying that way. I think what he is
>  talking about is that we are trying to get teams to support non-systemd
>  setups when upstreams do not, like with gnome.
> 
>  Gnome now has a hard dependency on systemd (for gnome newer than 3.8).
>  Some folks want to use gnome without systemd and are putting that under
>  the gentoo is about choice banner and want us to support them.
> 
>>> 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.
> 
> See above.
> 
> William
> 
If upstream gnome has that dep on systemd then I kinda think we should
too (technical decision, not one I like personally)

-- 
-- Matthew Thode (prometheanfire)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Daniel Campbell]

On 05/15/2013 08:41 AM, 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 (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.
> 

The solution is to pressure upstreams not to depend on a specific init
system in order to function. How many pieces of software depend on SysV,
runit, openrc, or upstart? The only ones I can think of are the pieces
that are designed specifically for making those init systems easier to
administer, not user-facing software like desktop environments.

I sincerely believe that each user and distro reserves the right to
choose which software to boot the system with, and desktop environments
and other user-facing software should not care about which init system
it's running on. In the case of GNOME, I think they're going too far by
depending on these things. GNOME devs haven't cared much for user
responses (especially wrt GTK+ 3.x), so they are likely to continue
integration with systemd. They're free to, but we're free to not use it,
too.

Personally, I will not have systemd on my box(es). I don't agree with
its motives, its methods, or its design. I will not use software that
depends on it. If the situation gets bad enough, then I may be forced to
switch to another OS... that bothers me, to a degree, but as long as
it's on my hardware, I have a say.

It would not bother me if distros ostracized Lennart and his projects
from the free software world, as he approaches free software with a
toxic attitude. We wouldn't miss much IMO.

As for Gentoo itself, I'm happy as long as choice remains the governing
principle.

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

[Duncan]

Rich Freeman posted on Wed, 15 May 2013 10:01:57 -0400 as excerpted:

> 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.

And in fact, that's already the case.

> 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.  :)

FWIW, of "the big two", gnome and kde seem to be going in totally 
opposite directions here.  Gnome, in accord with their "there can be only 
one true way" tendencies, seems to be hell-bent on requiring systemd, 
which of course then pretty well eliminates gnome on other than Linux as 
well.  Kde, OTOH, appears to be going totally opposite, more modular both 
with kde itself and with qt, thru the remaining gen-4 period and into 
gen-5 (qt5/kde5/kde-frameworks).

Much of kde is even running on MS these days, and it appears they plan on 
continuing both their BSD support and expanding the MS presence and 
support, as they go more modular for kde frameworks and individual app 
devs consider it appropriate.  As such, they're hard-rejecting a kde-wide 
hard-dep on systemd.  Instead, while individual systemd management 
components, etc, will likely require it (which makes sense given that's 
what they're /for, kde's grub management module makes little sense 
without grub, after all), everything else will work with it if it's 
there, or with other existing system services if they are there instead.

The same thing appears to be happening in kde for X and wayland.  Wayland 
support is definitely planned, with an early tech-preview release set for 
this summer I'm told, but AFAIK there's no plans to drop X support at 
least thru gen-5, kde5/frameworks, and qt5 is of course already 
supporting X, wayland and MS Windows (among others), with its 
multiplatform support being a primary feature point so qt isn't likely to 
dump that or it would simply no longer be qt as we know it.

Which leaves kde well positioned thru at least gen-5 to continue working 
and even expanding on all current platforms as well as chosen new ones.  
(FWIW, there are no plans at this point to support mir, however, as 
confirmed in a recent blog post.)

So while it's likely that over time it'll become more and more difficult 
to support gnome on anything but systemd-running Linux, with that an 
official upstream requirement, kde's going exactly the opposite 
direction, and plans on continuing to support and even expand its support 
both for the bsds and on ms, as well as continuing X support and adding 
wayland as it matures.  As such, they CANNOT hard-require systemd, and 
AFAIK aren't even planning on doing so on Linux, tho obviously kde does 
plan on supporting systemd for the distributions that run it.


So of the traditional big-two DEs, gnome would appear to be the only one 
with an announced hard-requirement of systemd.  I don't know what the 
"lighter" and traditionally anyway less popular gtk/gnome family of DEs, 
xfce, lxde, etc, are planning, but with kde going the opposite direction 
of gnome, it would seem a mistake to talk about the big DE's hard-
requiring systemd, and it getting harder and harder to run them on 
anything else.  Because really, that appears to be mainly gnome, only one 
of the big two.  So a more accurate statement would be gnome-specific, 
since they've already announced systemd to be a hard requirement for 
them, going forward.

-- 
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

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

[Luca Barbato]

On 05/15/2013 07:26 PM, Tom Wijsman wrote:
> On Wed, 15 May 2013 17:03:13 +0200
> Luca Barbato <lu_zero@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?

Luckily not, yet _that_'s what is in the roadmap apparently.

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

For any non-linux, less-than-3.x-linux, non-glibc system user probably.

> 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.

And that has my support, there is disagreement on what that entitles.

> 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...

Since it is the DE forcing all those changes down distribution throats.

lu

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

[Pacho Ramos]

El mié, 15-05-2013 a las 20:28 -0500, Matthew Thode escribió:
> On 05/15/13 19:27, William Hubbs wrote:
> > On Wed, May 15, 2013 at 10:16:01PM +0800, Ben de Groot wrote:
> >> 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.)
> > 
> > Udev doesn't force anything. In fact upstream makes it
> > clear that udev can be run without systemd.
> > 
> > William
> > 
> so then we should decouple logind from udev downstream (packaging) :D
> 

That is being handled in:
https://bugs.gentoo.org/show_bug.cgi?id=461940

but help is needed on that :|

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

[William Hubbs]

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

On Wed, May 15, 2013 at 04:08:17PM +0200, Pacho Ramos wrote:
> 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
 
 I don't either, but I do think this is why it was written -- to allow
 using gnome 3.6 without systemd.

> 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

I would be willing to consider this option.

Having systemd installed doesn't mean that you are running it, and there
are parts of the systemd package (like udev) that do not require
systemd to be running.

I don't know if there are any down sides to this arrangement other than
the extra disk space the systemd components would use.

This idea is probably a topic for another thread though.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Steven J. Long]

> William Hubbs wrote:
> > waltdnes 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.
> >  
> >  I don't interpret what he is saying that way. I think what he is
> >  talking about is that we are trying to get teams to support non-systemd
> >  setups when upstreams do not, like with gnome.
> > 
> >  Gnome now has a hard dependency on systemd (for gnome newer than 3.8).
> >  Some folks want to use gnome without systemd and are putting that under
> >  the gentoo is about choice banner and want us to support them.

I haven't seen anyone say that in this entire discussion, but I might have
missed something. "If a user wants to run GNOME, he [can] switch to systemd"
is clearly not saying that, so we're left with an enigmatic "some" who haven't
posted to this thread, afaics.

It's clear to me that users have been forced through lots of changes over the
last 5 years, even where we just want to carry on using our machines the way
we always have. Isn't that what convenience layers are about? So Walter's
point stands.

I for one have become very wary of accepting assurances that "nothing will
change" for existing users and their use-cases (since it's never proven
accurate from this upstream.) Especially when one init-system of several for
a niche operating-system becomes "the rest of the world."

> >> Fabio Erculiani wrote
> >>> 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.

Gnome can depend on w/e upstream require. How is that the whole world?
It's not even the whole Linux ecosystem, and I can't see Qt giving up cross-
platform independence, just to work with systemd. That was never going to
happen, so it was never going to happen in KDE either, however enthused a
few of its volunteers were, since KDE is a showcase for Qt.

You're right: reality-checks are clearly needed all over the place.

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

It's clear to me that systemd devs are the real isolationists: everyone
else has to do everything their way, or they'll throw their toys out of the
pram, including the ones they stole. The real trouble with "N+1 True Way" is
the contortions it forces them through, as they explain why "this time" they've
got it right, and how badly they got it wrong last time.

That wouldn't be an issue-- everyone makes mistakes-- if they hadn't rubbished
everyone else who pointed out issues along the way. After a few years of that,
sorry but enough already.

Matthew Thode wrote:
> If upstream gnome has that dep on systemd then I kinda think we should
> too (technical decision, not one I like personally)

I think we should too: all anyone has said is "Gnome is not Linux". Presenting
its choices as representative of every DE and upstream project is simply
misleading.

Claiming that making it easier to use systemd is in everyone's interests is
clearly untrue as well, since many of us our interests are caught up with a
modular system we can build and configure how we require. That's why we came to
Gentoo, and why we stay.

But I'm sure someone will declaim about how systemd doesn't force anything on
anyone (leveraging udev builds against your explicit word, doesn't count, nor do
any of the other changes like requiring an initramfs where none was needed before:
those are just things you should do because we tell you to) and Lennartware
hasn't already forced major changes and upgrade pain, for no tangible benefit to
the desktop-users it was purportedly aimed at.

I certainly haven't seen any new apps which weren't possible before, let alone a
class of them, which is what I'd expect in exchange for such intrusive breakages
of userspace. In fact, KDE works *better* without nubkit/ucrapola. Funny that.

By all means use your machines how you want, with whatever software you like.
Just respect our right to do the same: which includes the freedom NOT to use
software. If you cannot respect that choice (constantly trying to second-guess
our use-cases instead of accepting that actually we know them better than you,
and we don't want to have to file a bug and go through your mill every time we
want to do something "esoteric", that's why we use _soft_ware) then you cannot
expect much respect in return.

Courtesy, perhaps; if you don't spend an entire email belittling someone's
experience instead of answering the substantive points.

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

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

[William Hubbs]

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

On Fri, May 17, 2013 at 01:58:41AM +0100, Steven J. Long wrote:
> > William Hubbs wrote:
> > > waltdnes 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.
> > >  
> > >  I don't interpret what he is saying that way. I think what he is
> > >  talking about is that we are trying to get teams to support non-systemd
> > >  setups when upstreams do not, like with gnome.
> > > 
> > >  Gnome now has a hard dependency on systemd (for gnome newer than 3.8).
> > >  Some folks want to use gnome without systemd and are putting that under
> > >  the gentoo is about choice banner and want us to support them.
> 
> I haven't seen anyone say that in this entire discussion, but I might have
> missed something. "If a user wants to run GNOME, he [can] switch to systemd"
> is clearly not saying that, so we're left with an enigmatic "some" who haven't
> posted to this thread, afaics.
 
 The point I'm trying to make here is that for gnome >=3.8, upstream
 gnome does not support running gnome without systemd afaik.

> It's clear to me that users have been forced through lots of changes over the
> last 5 years, even where we just want to carry on using our machines the way
> we always have. Isn't that what convenience layers are about? So Walter's
> point stands.

No it doesn't, because Gentoo Linux isn't  requiring you to run systemd.
 
> > >> Fabio Erculiani wrote
> > >>> 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.
> 
> Gnome can depend on w/e upstream require. How is that the whole world?
> It's not even the whole Linux ecosystem, and I can't see Qt giving up cross-
> platform independence, just to work with systemd. That was never going to
> happen, so it was never going to happen in KDE either, however enthused a
> few of its volunteers were, since KDE is a showcase for Qt.
> 
> You're right: reality-checks are clearly needed all over the place.
> 
> > >>   You are effectively calling not-using-GNOME isolationist.  Let's just
> > >> say I disagree with you on that.  BTW, see my sig.
> 
> It's clear to me that systemd devs are the real isolationists: everyone
> else has to do everything their way, or they'll throw their toys out of the
> pram, including the ones they stole. The real trouble with "N+1 True Way" is
> the contortions it forces them through, as they explain why "this time" they've
> got it right, and how badly they got it wrong last time.
> 
> That wouldn't be an issue-- everyone makes mistakes-- if they hadn't rubbished
> everyone else who pointed out issues along the way. After a few years of that,
> sorry but enough already.
> 
> Matthew Thode wrote:
> > If upstream gnome has that dep on systemd then I kinda think we should
> > too (technical decision, not one I like personally)
> 
> I think we should too: all anyone has said is "Gnome is not Linux". Presenting
> its choices as representative of every DE and upstream project is simply
> misleading.
 
 I haven't done that, and I don't know of anyone else who has.

> Claiming that making it easier to use systemd is in everyone's interests is
> clearly untrue as well, since many of us our interests are caught up with a
> modular system we can build and configure how we require. That's why we came to
> Gentoo, and why we stay.
 
 No one is arguing against that. All this thread is about is making
 systemd a first-class citizen, like OpenRC/Sysvinit, so it will be as
 smooth as possible for someone who wants to switch between the two.

> But I'm sure someone will declaim about how systemd doesn't force anything on
> anyone (leveraging udev builds against your explicit word, doesn't count, nor do
> any of the other changes like requiring an initramfs where none was needed before:
> those are just things you should do because we tell you to) and Lennartware
> hasn't already forced major changes and upgrade pain, for no tangible benefit to
> the desktop-users it was purportedly aimed at.

Systemd has nothing to do with requiring an initramfs, so please
de-couple those issues. Yes, the systemd devs are the ones who wrote up
the issues around why an initramfs should be used if /usr is separate,
but systemd itself doesn't care.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Fabio Erculiani]

Good news.
I've been able to make logind work with OpenRC and GNOME 3.6 (which
means that GNOME 3.8 can work as well).
Disclaimer: I use systemd as device manager. I don't know if my logind
(there is a bug about it) works with udev without further hacking.
See: https://plus.google.com/u/0/107663298003289209275/posts/TxjqZkniR9f

Now, the problem is that, as I wrote before, we're more and more
drifting away from what upstream is supporting.
Today the source of all our troubles is just GNOME, I am afraid that
tomorrow it will expand beyond it. There are technical advantages for
both distro makers and desktop environment makers in using systemd
(besides the disadvantages). For instance, having a centralized tool
for collecting system and user logs is certainly something that would
make our job easier, having working (or mostly working) "init scripts"
provided directly by upstream projects would reduce our maintenance
burden in the long run.
Anyway, I'm not trying to convince anybody in using either init
systems, I am just suggesting that you should try both and decide
yourself. Which translated, is the same goal as making systemd more
accessible to you.

-- 
Fabio Erculiani

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

[Walter Dnes]

On Fri, May 17, 2013 at 10:45:18PM -0500, William Hubbs wrote

>  No one is arguing against that. All this thread is about is making
>  systemd a first-class citizen, like OpenRC/Sysvinit, so it will be as
>  smooth as possible for someone who wants to switch between the two.

   It seems that some of the proposals are crossing the line to make
systemd first-class and openrc second-class.  *THAT* is what's causing
the complaints.  The best analogy I can think of is the more extreme
type of "affirmative action" that effectively amounts to racial
discrimination against white people.  The pro-systemd group here is
advocating double-standards...

1) http://www.gossamer-threads.com/lists/gentoo/dev/272180?do=post_view_threaded

> 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.

  Yet openrc users are supposed to accept having their systems cluttered
with systemd units.

2) I suggested keying on a "systemd" USE flag, to inform portage whether
or not to install systemd units.  I was told that
https://bugs.gentoo.org/show_bug.cgi?id=198901 forbade using it that
way.  And therefore systemd config files would be installed regardless
of flags.  Therefore udev/eudev don't have "systemd" flags.  But both
have "openrc" flags, and will not run OK on an openrc machine without
the "openrc" flag.

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

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

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1676 bytes --]

Am Samstag, 18. Mai 2013, 19:02:12 schrieb Walter Dnes:

[snip]

> 
> > 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.
> 
>   Yet openrc users are supposed to accept having their systems cluttered
> with systemd units.
> 

This is getting more and more ridiculous. 

Next, systemd users will (correctly) remark that their systems are 
unnecessarily cluttered with openrc init scripts. 

Then, I may remark that my system is unnecessarily cluttered by quite some 
cmake modules that can search for libraries I'll never install. 

Not to speak of the boost sub-libraries that none of my installed packages 
uses.

Etc etc etc.

Please get a grip.

> 2) I suggested keying on a "systemd" USE flag, to inform portage whether
> or not to install systemd units.  I was told that
> https://bugs.gentoo.org/show_bug.cgi?id=198901 forbade using it that
> way.  And therefore systemd config files would be installed regardless
> of flags.  Therefore udev/eudev don't have "systemd" flags.  But both
> have "openrc" flags, and will not run OK on an openrc machine without
> the "openrc" flag.

The decision was made long ago. Use flags are not the correct way to control 
solely the installation of a few small files. 

If you really care (i.e. embedded systems), this is what install masks are 
for. Then just modify your /etc/make.conf accordingly. Believe me, that goes 
much faster than writing another discussion mail.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Rich Freeman]

On Sat, May 18, 2013 at 1:38 PM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> The decision was made long ago. Use flags are not the correct way to control
> solely the installation of a few small files.

This was really the heart of the discussion where the decision was made before.

USE flags should control things that affect dependencies, especially
linked dependencies. If a package wants to pull in systemd or link to
it, then it should have a USE flag if at all possible.  Likewise if a
package wants to pull in openrc or link to it then it should have a
USE flag.

When you're talking about just a few text files it isn't worth it.
Those who disagree can use INSTALL_MASK and nuke them from orbit.

Openrc isn't going anywhere as long as somebody cares to maintain it.
I don't see that changing anytime soon, and if it does change the only
thing its users can do is step up and maintain it (or pay somebody to
do it for them).  That's pretty-much how everything works on Gentoo,
or any other volunteer distro.  Don't worry about it - considering we
had a few devs step up and fork udev I doubt openrc is going away
anytime soon.

Rich

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

[Carlos Silva]

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

Is the real problem just the god damn unit/init files?! Damn, who cares
about 2KiB files in the age of GiBs?! You can install 1000 of them that it
will only take 2MiB of storage, so please, quit complaining about this.

One thing dev's should take care is (not that affects me, 'cause I really
don't care) is mentions to rc-update on einfo's. Again, I really don't
care, but, for the sake of making them (openrc, systemd, etc) equal, that
really shouldn't be mentioned.


On Sat, May 18, 2013 at 5:47 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, May 18, 2013 at 1:38 PM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
> > The decision was made long ago. Use flags are not the correct way to
> control
> > solely the installation of a few small files.
>
> This was really the heart of the discussion where the decision was made
> before.
>
> USE flags should control things that affect dependencies, especially
> linked dependencies. If a package wants to pull in systemd or link to
> it, then it should have a USE flag if at all possible.  Likewise if a
> package wants to pull in openrc or link to it then it should have a
> USE flag.
>
> When you're talking about just a few text files it isn't worth it.
> Those who disagree can use INSTALL_MASK and nuke them from orbit.
>
> Openrc isn't going anywhere as long as somebody cares to maintain it.
> I don't see that changing anytime soon, and if it does change the only
> thing its users can do is step up and maintain it (or pay somebody to
> do it for them).  That's pretty-much how everything works on Gentoo,
> or any other volunteer distro.  Don't worry about it - considering we
> had a few devs step up and fork udev I doubt openrc is going away
> anytime soon.
>
> Rich
>
>

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

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

[William Hubbs]

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

On Sat, May 18, 2013 at 01:02:12PM -0400, Walter Dnes wrote:
> On Fri, May 17, 2013 at 10:45:18PM -0500, William Hubbs wrote
> 
> >  No one is arguing against that. All this thread is about is making
> >  systemd a first-class citizen, like OpenRC/Sysvinit, so it will be as
> >  smooth as possible for someone who wants to switch between the two.
> 
>    It seems that some of the proposals are crossing the line to make
> systemd first-class and openrc second-class.  *THAT* is what's causing
> the complaints.  The best analogy I can think of is the more extreme
> type of "affirmative action" that effectively amounts to racial
> discrimination against white people.  The pro-systemd group here is
> advocating double-standards...
> 
> 1) http://www.gossamer-threads.com/lists/gentoo/dev/272180?do=post_view_threaded
> 
> > 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.
 
 Agreed, I don't propose having a package that installs all of the
 systemd units.

>   Yet openrc users are supposed to accept having their systems cluttered
> with systemd units.
> 
> 2) I suggested keying on a "systemd" USE flag, to inform portage whether
> or not to install systemd units.  I was told that
> https://bugs.gentoo.org/show_bug.cgi?id=198901 forbade using it that
> way.  And therefore systemd config files would be installed regardless
> of flags.  Therefore udev/eudev don't have "systemd" flags.  But both
> have "openrc" flags, and will not run OK on an openrc machine without
> the "openrc" flag.

We do that because there is a separate package (udev-init-scripts) in
the tree which has the OpenRC init scripts for udev and eudev. Both of
them have RDEPENDS on this package if the openrc use flag is set.

Also, there are some udev rules in the udev-init-scripts package which
should not be installed if openrc is not in use.

So, the use flag does more than just not install init scripts.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Mol]

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

On 05/18/2013 03:23 PM, Carlos Silva wrote:
> Is the real problem just the god damn unit/init files?! Damn, who cares
> about 2KiB files in the age of GiBs?! You can install 1000 of them that
> it will only take 2MiB of storage, so please, quit complaining about this.

Practically speaking, I think the problem is likely more about the inode
usage than the physical size of the files. With today's huge disks, the
problem does seem to be becoming the cost of metadata over the cost of
the data itself. (Why else would we need sectors larger than 512 bytes?)

> 
> One thing dev's should take care is (not that affects me, 'cause I
> really don't care) is mentions to rc-update on einfo's. Again, I really
> don't care, but, for the sake of making them (openrc, systemd, etc)
> equal, that really shouldn't be mentioned.

[snip]



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 873 bytes --]

Am Sonntag, 19. Mai 2013, 14:59:21 schrieb Michael Mol:
> On 05/18/2013 03:23 PM, Carlos Silva wrote:
> > Is the real problem just the god damn unit/init files?! Damn, who cares
> > about 2KiB files in the age of GiBs?! You can install 1000 of them that
> > it will only take 2MiB of storage, so please, quit complaining about
> > this.
> 
> Practically speaking, I think the problem is likely more about the inode
> usage than the physical size of the files. With today's huge disks, the
> problem does seem to be becoming the cost of metadata over the cost of
> the data itself. (Why else would we need sectors larger than 512 bytes?)

Then use a decent file system.
http://kernelnewbies.org/Linux_3.8#head-372b38979138cf2006bd0114ae97f889f67ef46a
EOT

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[J. Roeleveld]

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

"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

>Am Sonntag, 19. Mai 2013, 14:59:21 schrieb Michael Mol:
>> On 05/18/2013 03:23 PM, Carlos Silva wrote:
>> > Is the real problem just the god damn unit/init files?! Damn, who
>cares
>> > about 2KiB files in the age of GiBs?! You can install 1000 of them
>that
>> > it will only take 2MiB of storage, so please, quit complaining
>about
>> > this.
>> 
>> Practically speaking, I think the problem is likely more about the
>inode
>> usage than the physical size of the files. With today's huge disks,
>the
>> problem does seem to be becoming the cost of metadata over the cost
>of
>> the data itself. (Why else would we need sectors larger than 512
>bytes?)
>
>Then use a decent file system.
>http://kernelnewbies.org/Linux_3.8#head-372b38979138cf2006bd0114ae97f889f67ef46a
>EOT
>
>-- 
>
>Andreas K. Huettel
>Gentoo Linux developer 
>dilfridge@gentoo.org
>http://www.akhuettel.de/

Andreas.

I don't see how this will avoid the issue of a limited amount of inodes.
That is what I usually run out of before the disk is full when storing lots of smaller files.

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

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

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

[Peter Stuge]

J. Roeleveld wrote:
> I don't see how this will avoid the issue of a limited amount of
> inodes.
> That is what I usually run out of before the disk is full when
> storing lots of smaller files.

I guess the number of unit files is on the order of hundreds, as long
as you haven't configured an INSTALL_MASK to avoid installing them.
(Why haven't you?)

Are you saying that a few hundred inodes more will break many systems?

It doesn't seem very likely to me.


//Peter

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

[Canek Peláez Valdés]

On Sun, May 19, 2013 at 9:34 AM, Peter Stuge <peter@stuge.se> wrote:
> J. Roeleveld wrote:
>> I don't see how this will avoid the issue of a limited amount of
>> inodes.
>> That is what I usually run out of before the disk is full when
>> storing lots of smaller files.
>
> I guess the number of unit files is on the order of hundreds,

Full GNOME


 as long
> as you haven't configured an INSTALL_MASK to avoid installing them.
> (Why haven't you?)
>
> Are you saying that a few hundred inodes more will break many systems?
>
> It doesn't seem very likely to me.
>
>
> //Peter
>



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

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

[Canek Peláez Valdés]

On Sun, May 19, 2013 at 9:34 AM, Peter Stuge <peter@stuge.se> wrote:
> J. Roeleveld wrote:
>> I don't see how this will avoid the issue of a limited amount of
>> inodes.
>> That is what I usually run out of before the disk is full when
>> storing lots of smaller files.
>
> I guess the number of unit files is on the order of hundreds

(Sorry, sent email before it was ready).

Laptop running full GNOME:

# find /usr/lib/systemd/system -type f | wc
    154     154    7012

Server running Apache+MySQL+Mailman+Squid+Other services:

# find /usr/lib/systemd/system -type f | wc
    121     121    5560

And as you said, you can always use INSTALL_MASK. If 154 files are
going to deplete your inodes, I think your problem lies somewhere
else.

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

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

[Daniel Campbell]

On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote:
> On Sun, May 19, 2013 at 9:34 AM, Peter Stuge <peter@stuge.se> wrote:
>> J. Roeleveld wrote:
>>> I don't see how this will avoid the issue of a limited amount of
>>> inodes.
>>> That is what I usually run out of before the disk is full when
>>> storing lots of smaller files.
>>
>> I guess the number of unit files is on the order of hundreds
> 
> (Sorry, sent email before it was ready).
> 
> Laptop running full GNOME:
> 
> # find /usr/lib/systemd/system -type f | wc
>     154     154    7012
> 
> Server running Apache+MySQL+Mailman+Squid+Other services:
> 
> # find /usr/lib/systemd/system -type f | wc
>     121     121    5560
> 
> And as you said, you can always use INSTALL_MASK. If 154 files are
> going to deplete your inodes, I think your problem lies somewhere
> else.
> 
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
> 

That's missing the point. If you don't run systemd, having unit files is
pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
like a hack instead of something more robust. Why include systemd unit
files (by default, with no systemd USE flag, thanks to the council...)
on a system that's not using it? 154 files isn't negligible unless
you're flippant with your system and don't care about bloat. Unused
software sitting around *is* a waste of disk-space.

Some people (like myself) came to Gentoo to avoid putting systemd on
their systems and to make use of the great choice that Gentoo allows.
This push to make systemd a "first level citizen" or whatever reeks of
marketing. If there is desire among users for unit files, they can
contact upstream or maintain their own set of unit files. It's not like
they're hard to write.

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

[Canek Peláez Valdés]

On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell <dlcampbell@gmx.com> wrote:
> On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote:
>> On Sun, May 19, 2013 at 9:34 AM, Peter Stuge <peter@stuge.se> wrote:
>>> J. Roeleveld wrote:
>>>> I don't see how this will avoid the issue of a limited amount of
>>>> inodes.
>>>> That is what I usually run out of before the disk is full when
>>>> storing lots of smaller files.
>>>
>>> I guess the number of unit files is on the order of hundreds
>>
>> (Sorry, sent email before it was ready).
>>
>> Laptop running full GNOME:
>>
>> # find /usr/lib/systemd/system -type f | wc
>>     154     154    7012
>>
>> Server running Apache+MySQL+Mailman+Squid+Other services:
>>
>> # find /usr/lib/systemd/system -type f | wc
>>     121     121    5560
>>
>> And as you said, you can always use INSTALL_MASK. If 154 files are
>> going to deplete your inodes, I think your problem lies somewhere
>> else.
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>> Posgrado en Ciencia e Ingeniería de la Computación
>> Universidad Nacional Autónoma de México
>>
>
> That's missing the point. If you don't run systemd, having unit files is
> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
> like a hack instead of something more robust. Why include systemd unit
> files (by default, with no systemd USE flag, thanks to the council...)
> on a system that's not using it? 154 files isn't negligible unless
> you're flippant with your system and don't care about bloat. Unused
> software sitting around *is* a waste of disk-space.

Unit files are not software; they are data.

And I believe you are the one missing the point. I don't run OpenRC; I
don't need no files in /etc/init.d. But you don't see me (nor any
other systemd user) complaining about pointless scripts in
/etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with my
life.

Non-systemd users should do the same for files under /usr/lib/systemd,
if they really are that worried about systemd "infecting" their
systems. Complaining about a council-decided policy (and, I believe,
backed up by the developers that matter, including the OpenRC
maintainers) is just beating on a dead horse.

Get over it.

> Some people (like myself) came to Gentoo to avoid putting systemd on
> their systems and to make use of the great choice that Gentoo allows.
> This push to make systemd a "first level citizen" or whatever reeks of
> marketing.

If Gentoo is about choice, then systemd is one of those choices. And
systemd will become a first class citizen inside Gentoo, like it or
not. Support for it has been getting better and better, and more and
more Gentoo users are running with systemd.

If  some fundamentalists users don't want even one file in their
systems with "systemd" on their paths, they can install eudev/mdev,
put the necessary directories in INSTALL_MASK, and do the extra work.
If some other fundamentalists users (like myself) don't want even one
OpenRC related file on our systems, we can create an overlay to remove
the dependency of baselayout on OpenRC, put /etc/init.d in
INSTALL_MASK, and do the extra work.

Neither case covers the average systemd/OpenRC user, who doesn't care
about a few scattered files in /etc/init.d nor /usr/lib/systemd, and
just want to run her machine with the init system of her choice. If
Gentoo is really about choice.

> If there is desire among users for unit files, they can
> contact upstream or maintain their own set of unit files. It's not like
> they're hard to write.

So, Gentoo is about choice, but only for the choices you agree with. Great.

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

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

[Duncan]

Daniel Campbell posted on Mon, 20 May 2013 22:03:02 -0500 as excerpted:

> [100-200 systemd unit files is] missing the point.
> If you don't run systemd, having unit files is
> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
> like a hack instead of something more robust. Why include systemd unit
> files (by default, with no systemd USE flag, thanks to the council...)
> on a system that's not using it? 154 files isn't negligible unless
> you're flippant with your system and don't care about bloat. Unused
> software sitting around *is* a waste of disk-space.
> 
> Some people (like myself) came to Gentoo to avoid putting systemd on
> their systems and to make use of the great choice that Gentoo allows.
> This push to make systemd a "first level citizen" or whatever reeks of
> marketing.

But the point you're missing is that INSTALL_MASK is NOT a hack.  It's a 
specifically designed part of the whole gentoo support of choice system 
you mention, designed precisely to allow users a supported method of 
vetoing specific files on their system, should they wish to do so.

Which is what the council decision effectively said as well.  Gentoo 
already has tools designed to allow users to veto specific files should 
they choose to do so, so putting individual files under control of a USE 
flag is an over-engineered hassle, both to the users who find they have 
to remerge an entire package, often rebuilding from source, just to get a 
trivial sized file that would have otherwise been there, and that wasn't 
doing any harm in any case, and to the devs who end up maintaining these 
USE flags for trivial files, when there's already a perfectly usable 
solution specifically designed to give users who want to veto specific 
files on their systems the ability to do so.

You're at once claiming that gentoo's about choice, and disparaging one 
of the tools specifically designed to aid in giving you that choice.  
Just use the tool for the precise purpose it's designed for, and quit 
worrying about it.


FWIW, all this said as a user who's still very much personally in the 
openrc camp, and in fact chooses to use /another/ such tool, 
package.keywords, to keyword-unmask openrc-9999 **, so I can run the live-
git version and follow commits and git logs individually, the better to 
trace problems down to the source as soon as they appear. =:^)

In fact, I use many such tools, package.keywords and package.umask as 
well as layman overlays to run testing and live-git versions of various 
packages, the portage/profile subdir to negate all packages that would 
otherwise appear in my @system so it's entirely empty (helps portage make 
better use of its parallel build capacities, among other things),
/etc/portage/sets/* and /var/lib/portage/world_sets support to categorize 
all packages formerly listed in world into sets, so my world file is 
empty as well, and yes, INSTALL_MASK and PKG_INSTALL_MASK, to veto most 
*.la files among other things, along with individual /etc/portage/env/* 
files to setup individual package exceptions to that general *.la veto, 
where necessary.

If these tools, all part of the gentoo's about choice value you mention, 
are hacks, then gentoo itself is a hack, and if you don't like it, you 
better find yourself a distribution that relies less on such "hacks".  
No, these are NOT "hacks", they're specific features specifically 
engineered to make specific bits of that "gentoo's about choice" thing 
work, in fact giving individual site/installation admins that very choice.

Us the tools for what they're designed for, and the problem disappears.
Both openrc users wishing to veto system support files and systemd users 
wishing to veto openrc files get to do just that, using a tool precisely 
designed to allow them to veto such files should they decide the want 
to.  So where's the problem?  It's gone!  Vanished due to use of a tool 
exactly as it was intended to be used! =:^)

(All that said, if Zac saw fit to add a nounits feature to the already 
existing nodoc/noinfo/noman features, I doubt anyone would object.  Like 
them, the feature would be simplified but redundant method of doing what 
INSTALL_MASK already makes possible, but simplified /is/ perhaps the key 
word here.  Has anyone so strongly objecting to using INSTALL_MASK as it 
was intended to be used proposed such a patch?  You'd have to ask Zac if 
he'd consider taking it, but given the precedent set by the other no* 
features, there's certainly hope.  =:^)

-- 
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

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

[Alan McKinnon]

On 21/05/2013 05:03, Daniel Campbell wrote:
> That's missing the point. If you don't run systemd, having unit files is
> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
> like a hack instead of something more robust. Why include systemd unit
> files (by default, with no systemd USE flag, thanks to the council...)
> on a system that's not using it? 154 files isn't negligible unless
> you're flippant with your system and don't care about bloat. Unused
> software sitting around *is* a waste of disk-space.
> 
> Some people (like myself) came to Gentoo to avoid putting systemd on
> their systems and to make use of the great choice that Gentoo allows.
> This push to make systemd a "first level citizen" or whatever reeks of
> marketing. If there is desire among users for unit files, they can
> contact upstream or maintain their own set of unit files. It's not like
> they're hard to write.
> 

<amused long-term user chipping in>

This is such a weak argument it's quite laughable.

I don't like gnu info files. Neither me nor anyone I know can figure out
how to drive info. So, let's rip all the info files out of every
package; leaving the 3 users who do know info free to grab their copies
from upstream. I mean it's not like it's hard or anything, and info
files are easy to write.

Daniel, you should just get over it. Having choices means you let the
other guy have his choices too. Sometimes that means you have to let
that guy have a little bit of his infra lying around so his choice is
possible. And no-one ever said having choices means your exact personal
preferences wrt every little thing will be baked in.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Michał Górny]

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

On Tue, 21 May 2013 09:03:54 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 21/05/2013 05:03, Daniel Campbell wrote:
> > That's missing the point. If you don't run systemd, having unit files is
> > pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
> > like a hack instead of something more robust. Why include systemd unit
> > files (by default, with no systemd USE flag, thanks to the council...)
> > on a system that's not using it? 154 files isn't negligible unless
> > you're flippant with your system and don't care about bloat. Unused
> > software sitting around *is* a waste of disk-space.
> > 
> > Some people (like myself) came to Gentoo to avoid putting systemd on
> > their systems and to make use of the great choice that Gentoo allows.
> > This push to make systemd a "first level citizen" or whatever reeks of
> > marketing. If there is desire among users for unit files, they can
> > contact upstream or maintain their own set of unit files. It's not like
> > they're hard to write.
> > 
> 
> <amused long-term user chipping in>
> 
> This is such a weak argument it's quite laughable.
> 
> I don't like gnu info files. Neither me nor anyone I know can figure out
> how to drive info.

Arrows move the cursor, enter follows links, '/' searches. And don't
dare touch anything else because nobody knows what could happen!

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Albert Hopkins]

On Mon, May 20, 2013, at 11:03 PM, Daniel Campbell wrote:

> That's missing the point. If you don't run systemd, having unit files is
> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
> like a hack instead of something more robust. Why include systemd unit
> files (by default, with no systemd USE flag, thanks to the council...)
> on a system that's not using it? 154 files isn't negligible unless
> you're flippant with your system and don't care about bloat. Unused
> software sitting around *is* a waste of disk-space.
> 

You've either won the "Unreasonably Pedantic Award" or the "Will Say Any
Stupid Thing Prove His/Her Point Award".  Please let me know which one
to send to you.

-a

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

[Rich Freeman]

On Mon, May 20, 2013 at 11:03 PM, Daniel Campbell <dlcampbell@gmx.com> wrote:
> <something truly astonishing>

Well, I have to at least thank you for turning this from just a
typical Gentoo flame-war into a breeding ground for LWN Quote of the
Week candidates.

Rich

[gentoo-dev] TLDNR; Re: Making systemd more accessible to "normal" users

[Steven J. Long]

William Hubbs wrote:
> Steven J. Long wrote:
> > I haven't seen anyone say that in this entire discussion, but I might have
> > missed something. "If a user wants to run GNOME, he [can] switch to systemd"
> > is clearly not saying that, so we're left with an enigmatic "some" who haven't
> > posted to this thread, afaics.
>  
>  The point I'm trying to make here is that for gnome >=3.8, upstream
>  gnome does not support running gnome without systemd afaik.

Then I don't know why you think repeating stuff we already know adds anything to the
discussion.

The point you actually made was:
> Some folks want to use gnome without systemd and are putting that under the gentoo
> is about choice banner and want us to support them.

And that's what I answered, so my point still stands, in response to what you
actually wrote.
 
> > It's clear to me that users have been forced through lots of changes over the
> > last 5 years, even where we just want to carry on using our machines the way
> > we always have. Isn't that what convenience layers are about? So Walter's
> > point stands.
> 
> No it doesn't, because Gentoo Linux isn't  requiring you to run systemd.

Again, you appear to be deliberately misrepresenting the discussion, this time in order
to make it just about whether one must run systemd or not. That's not the only concern.
Nor have the changes that have been forced upon users by this upstream, to zero
tangible benefit afaic but causing an awful lot of pain, been restricted to systemd;
the "last 5 years" I referred to.

This is the point Walter actually made:
>> 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.

Your strawman is that no-one is talking about anything but GNOME. Yet in another post
we have:

> Today the source of all our troubles is just GNOME, I am afraid that tomorrow it
> will expand beyond it. 

The usual eleventy-eleven nonsense, akin to the nonsense about split /usr being "broken",
and here's a load of spurious reasons why from people who never saw the point, so let's
change everyone's setup, when /really/ it was just about udev initscripts requiring /usr.
And delaying start till  after localmount if you have stuff for rootfs builtin (which most
of us do after an install: that's how we booted to setup the rest of the system) works
perfectly well, without requiring you to throw another point of failure and maintenance
into the mix.

So, lots of changes foisted upon us, to support corner-cases that aren't even designed
very well[1], and will require more changes in the future, since upstream think they
know better than everyone else.

*Making the simple cases complex, to support the complex ones is simply doing it wrong.*

Especially when your idiot-box can't cope with unexpected situations, and instead you
rely on rubbishing users' experience, with a patronising "no-one needs that" so you
don't even support the complex cases very well. Mainly because you refuse to keep it
simple, as you want to display your virtuosity, instead of providing tools that users
and other developers can tie together as they see fit.

"Tail wagging the dog" sounds exactly right. So Walter's point still stands imo.
When you forego modularity, you get a ripple effect of changes. Exactly what we've
seen happen more and more over the last 5 years.

Providing mechanisms to handle the complex cases, or to allow the user to handle them,
is fine. Just don't wag the dog.
  
> > > >> Fabio Erculiani wrote
> > > >>> So what do we want to do then? Isolate from the rest of the world?

> > Gnome can depend on w/e upstream require. How is that the whole world?
> > It's not even the whole Linux ecosystem, and I can't see Qt giving up cross-
> > platform independence, just to work with systemd. That was never going to
> > happen, so it was never going to happen in KDE either, however enthused a
> > few of its volunteers were, since KDE is a showcase for Qt.
> > 

> > Matthew Thode wrote:
> > > If upstream gnome has that dep on systemd then I kinda think we should
> > > too (technical decision, not one I like personally)
> > 
> > I think we should too: all anyone has said is "Gnome is not Linux". Presenting
> > its choices as representative of every DE and upstream project is simply
> > misleading.
>  
>  I haven't done that, and I don't know of anyone else who has.

"the rest of the world" and the above comment quoted seem pretty clear to me.

So we agree it's only GNOME-3 that has the hard requirement on systemd. KDE, the other
big DE, which ime has brought more non-Linux users to Linux than any other, and
certainly represents the only one left of the two which still works like a desktop,
has no such limitation. Neither do the forks of GNOME-2, nor lxde, and indeed people
have original GNOME-2 working without polkit, let alone systemd.

> > Claiming that making it easier to use systemd is in everyone's interests is
> > clearly untrue as well, since many of us our interests are caught up with a
> > modular system we can build and configure how we require. That's why we came to
> > Gentoo, and why we stay.
>  
>  No one is arguing against that. All this thread is about is making
>  systemd a first-class citizen, like OpenRC/Sysvinit, so it will be as
>  smooth as possible for someone who wants to switch between the two.

I wasn't aware it was a second-class citizen. Both seem fairly equal to my eyes: as
people contribute or use them, they evolve in Gentoo. OFC openrc has less evolution
to do, since it's more mature, and lets existing software do its job instead of trying
to supplant it.

This thread started out as suggesting an eselect mechanism that is unnecessary and in
fact counter-productive in implementation. The effort should go into making sure the
user's system is in a state that can be booted, not into automating the edit of a single
file by instead changing symlink and hoping nothing goes wrong.

And if it does, the user he thinks incapable of editing a file, will instead have to
edit the bootloader config at startup to use a non-standard filename (just what Grandma
is good at), and then reset the symlink (or rely on the ill-conceived automated mechanism
that got her into the mess), instead of a new option to try the config out, and then
confirm the change, or take a successful boot/one-time service startup as confirmation.

Is it just me who thinks developer effort and future maintenance for something that
is badly designed, is a complete waste of time, and a dead-end?

More to the point, why is it so unacceptable for me to question an implementation, on
a list designed for that purpose?

Anyhow, if you could elucidate on where you think systemd is being treated as a
"second-class citizen" and not the same as any other Gentoo software, that would be
useful for the issues to be addressed. afaict systemd-udev seems to get far more
attention than other software projects in Gentoo, usually when it's breaking existing
setups and there's a campaign around how great that is for everyone.

An eselect for init symlink being a bad idea is not treating either project better
or worse. It's just saying that's a bad way to switch, and why not spend the effort
on the bit that matters, ie making sure the system is safe to switch in the first
place, since it hasn't even been mentioned *at all*.

As you get older, you actually appreciate those moments (which are the aim of this list)
for the amount of work they save you. Though by then, you've got used to being wrong,
and see the process as more about the mistakes you didn't make, than how much code you
produced. Simpler and less code is easier to read, write, maintain, easier to optimise,
and runs quicker.

When you're young you attach more ego to your output, and get hostile and defensive
instead, resorting to insults about the person questioning you, instead of considering
what they actually typed, and whether it has any validity, and answering the substance.

> > But I'm sure someone will declaim about how systemd doesn't force anything on
> > anyone (leveraging udev builds against your explicit word, doesn't count, nor do
> > any of the other changes like requiring an initramfs where none was needed before:
> > those are just things you should do because we tell you to) and Lennartware
> > hasn't already forced major changes and upgrade pain, for no tangible benefit to
> > the desktop-users it was purportedly aimed at.
> 
> Systemd has nothing to do with requiring an initramfs, so please
> de-couple those issues. Yes, the systemd devs are the ones who wrote up
> the issues around why an initramfs should be used if /usr is separate,
> but systemd itself doesn't care.

IOW "because we tell you to." (See above wrt the actual technical issue, which is
not about the rest of the ecosystem at all. Tacking on a discussion about the crap
linkage in Linux, which is actually due to gmake insanity and should be fixed, doesn't
change that. A small proportion of the effort that's gone into keeping up with upstream
changes could have sorted out the /usr,root split out far more effectively across distros
and projects, not that it is much of an issue in practice, thanks to a sane base-system.)

Your argument is disingenuous at best. It's one thing to flag an issue that /might/ affect
people, or indeed to use an initramfs in the binary distro you work for. It's quite
another to conduct a public campaign to rubbish a partitioning split that was worked out
30 years ago, and is still used by many admins for good reasons (and no, I don't have
to enumerate them for them to be valid. You guys are supposed to make our life easier,
not harder: and that means accepting we know what we're doing better than you do, since
by definition you are not around when the software is in-use.) As Linus said if
something's been around for 30 years, it's not a reason to get rid of it:
"if anything, damn that thing works."

Quite apart from anything else, continually rubbishing a lean rootfs combined with split
/usr /var /home et al, makes you sound like a nub to people who've been very successful
for decades, with that setup. Irrespective of what Sun did to evade the issue or the
reasons they might have had within their setup that simply do not apply to Gentoo users.
(no one mentions /usr/xpg4/bin for some reason, but somehow Sun is the model we should
aspire to when it comes to laying out our filesystem.)

Most especially when your propaganda page in favour of the "new" setup actually resorts
to quoting lots of the advantages of that exact same "old" setup.

Only this time the initramfs is both the new rootfs we should rely on to recover our
systems, and simultaneously a minimal little thing we shouldn't worry our heads about.
(Coming from the people who've told us that so many times, yet ended up causing us a lot
of worry and admin effort, it's hard to believe.)
Or maintain another partition with a whole live-disk in, and keep that up to date as well.

Or just ignore the latest "One True Way" and laugh at the fact that it's actually become
"N+1 True Way" since history's lessons have to be learnt anew, and the whole point of
being young is to reject what you've been told, and make your own mind up.

It's all very well to evolve software over time. However, "plan to throw one away,
you will anyway" has become "plan to throw _every_ version away, since we can't get a
design right, and we're in userspace so we don't have to think about ABI, all good.
Can I interest you in a binary log stuffed with XML?"

And while every software has bugs, that's not a reason to forego any sort of
acceptance-testing with the network admins you claim to want to help, and instead
dump half-baked software into the wild, with the immortal words "it's free, c'mon
we give you this stuff for free", backed up by a chorus of "the source is out there"
and "no we don't want nor need, no steenking modularity, cohesion or portability,
that's fusty traditional Unix."

Please note: I was in favour of making it easy to switch between openrc and systemd, and
still am. I am also in favour of GNOME-3 in Gentoo simply requiring systemd.

And I have consistently supported unit files being installed by default, so that
sub-thread has got nothing to do with anything I've said.

Regards,
igli.

[1] http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

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

[Michael Mol]

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

On 05/20/2013 11:34 PM, Canek Peláez Valdés wrote:
> On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell <dlcampbell@gmx.com>
> wrote:

[snip]

>> That's missing the point. If you don't run systemd, having unit 
>> files is pointless. Thankfully there's INSTALL_MASK and whatnot, 
>> but that seems like a hack instead of something more robust. Why 
>> include systemd unit files (by default, with no systemd USE flag, 
>> thanks to the council...) on a system that's not using it? 154 
>> files isn't negligible unless you're flippant with your system and
>>  don't care about bloat. Unused software sitting around *is* a 
>> waste of disk-space.
> 
> Unit files are not software; they are data.

That's like saying "shell scripts are not software, they are data". Unit
files, semantically and collectively, are a system-behavior-defining set
of interpreted modules written in a declarative language. In fact,
that's what makes them even remotely appealing, on comparison to
shell-based init scripts; they make declarations of requirements, the
"what", and leave it to the system resolver to work out the "how".

(It's from this perspective that I like the idea of using unit files as
a point of origin for *generating* init configurations like systemv,
openrc or runit scripts. You'd be compiling the init script for the
target init system, and your result should be more robust for it.)

> 
> And I believe you are the one missing the point. I don't run OpenRC;
>  I don't need no files in /etc/init.d. But you don't see me (nor any
>  other systemd user) complaining about pointless scripts in 
> /etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with
> my life.
> 
> Non-systemd users should do the same for files under 
> /usr/lib/systemd, if they really are that worried about systemd 
> "infecting" their systems. Complaining about a council-decided policy
> (and, I believe, backed up by the developers that matter, including
> the OpenRC maintainers) is just beating on a dead horse.

The push to keep USE flags specific to enabling and disabling program
features seems weird to me; the semantics of USE flags seem valuable for
a great deal more than that.

> 
> Get over it.
> 
>> Some people (like myself) came to Gentoo to avoid putting systemd 
>> on their systems and to make use of the great choice that Gentoo 
>> allows. This push to make systemd a "first level citizen" or 
>> whatever reeks of marketing.
> 
> If Gentoo is about choice, then systemd is one of those choices.

This I take no issue with.

> And systemd will become a first class citizen inside Gentoo, like it
>  or not.

...

> Support for it has been getting better and better, and more and more 
> Gentoo users are running with systemd.

And users are switching to eudev and mdev as well. Personally, I think
heterogeneity is a good thing...That's a huge part of why I like Gentoo;
it's a crucible for open-source software that tends to bring breakages
in edge-case (but theoretically "supported") configurations to upstream
attention.

> 
> If  some fundamentalists

...

> users don't want even one file in their systems with "systemd" on
> their paths, they can install eudev/mdev, put the necessary
> directories in INSTALL_MASK, and do the extra work. If some other
> fundamentalists users (like myself) don't want even one OpenRC
> related file on our systems, we can create an overlay to remove the
> dependency of baselayout on OpenRC, put /etc/init.d in INSTALL_MASK,
> and do the extra work.
> 
> Neither case covers the average systemd/OpenRC user, who doesn't
> care about a few scattered files in /etc/init.d nor /usr/lib/systemd,
> and just want to run her machine with the init system of her choice.
> If Gentoo is really about choice.

It is, and it should be.

> 
>> If there is desire among users for unit files, they can contact 
>> upstream or maintain their own set of unit files. It's not like 
>> they're hard to write.
> 
> So, Gentoo is about choice, but only for the choices you agree with.
>  Great.

Nobody says the devs must do whatever the users demand of them; the devs
are unpaid.

The best arguments in this thread, to my eye, have been to encourage
devs to accept user-contributed unit files.

As users, you and I can't force devs to do anything. But we can always
pull up our sleeves and dig in ourselves.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Ciaran McCreesh]

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

On Tue, 21 May 2013 04:45:12 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> But the point you're missing is that INSTALL_MASK is NOT a hack.

Sure it is. It's a hack and remains a hack until there's a way of using
it without risk of breakage.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Mol]

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

On 05/21/2013 09:50 AM, Ciaran McCreesh wrote:
> On Tue, 21 May 2013 04:45:12 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>> But the point you're missing is that INSTALL_MASK is NOT a hack.
> 
> Sure it is. It's a hack and remains a hack until there's a way of using
> it without risk of breakage.
> 

That's a silly requirement. Every time I sit down with one of my systems
and start playing/exploring (If I've gone a month without getting
somewhat competent with something completely new to me, it's been a bad
month) with USE flags, I break my system with within hours. USE flags
are awesome at what they do, and they're incredibly robust, but that
doesn't mean that toggling features on and off isn't dangerous.

On a working system, *anything* you might touch in
/etc/portage/make.conf carries with it the risk of breakage. This is
what makes Gentoo a place for people who are willing to get their hands
dirty understanding how their system works.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Ciaran McCreesh]

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

On Tue, 21 May 2013 09:57:53 -0400
Michael Mol <mikemol@gmail.com> wrote:
> On 05/21/2013 09:50 AM, Ciaran McCreesh wrote:
> > On Tue, 21 May 2013 04:45:12 +0000 (UTC)
> > Duncan <1i5t5.duncan@cox.net> wrote:
> >> But the point you're missing is that INSTALL_MASK is NOT a hack.
> > 
> > Sure it is. It's a hack and remains a hack until there's a way of
> > using it without risk of breakage.
> 
> That's a silly requirement. Every time I sit down with one of my
> systems and start playing/exploring (If I've gone a month without
> getting somewhat competent with something completely new to me, it's
> been a bad month) with USE flags, I break my system with within
> hours. USE flags are awesome at what they do, and they're incredibly
> robust, but that doesn't mean that toggling features on and off isn't
> dangerous.

And you're reporting bugs for all these missing or automagic
dependencies, right?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Mol]

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

On 05/21/2013 10:02 AM, Ciaran McCreesh wrote:
> On Tue, 21 May 2013 09:57:53 -0400
> Michael Mol <mikemol@gmail.com> wrote:
>> On 05/21/2013 09:50 AM, Ciaran McCreesh wrote:
>>> On Tue, 21 May 2013 04:45:12 +0000 (UTC)
>>> Duncan <1i5t5.duncan@cox.net> wrote:
>>>> But the point you're missing is that INSTALL_MASK is NOT a hack.
>>>
>>> Sure it is. It's a hack and remains a hack until there's a way of
>>> using it without risk of breakage.
>>
>> That's a silly requirement. Every time I sit down with one of my
>> systems and start playing/exploring (If I've gone a month without
>> getting somewhat competent with something completely new to me, it's
>> been a bad month) with USE flags, I break my system with within
>> hours. USE flags are awesome at what they do, and they're incredibly
>> robust, but that doesn't mean that toggling features on and off isn't
>> dangerous.
> 
> And you're reporting bugs for all these missing or automagic
> dependencies, right?
> 

Actually, yes.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

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

[Duncan]

Ciaran McCreesh posted on Tue, 21 May 2013 14:50:04 +0100 as excerpted:

> On Tue, 21 May 2013 04:45:12 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>> But the point you're missing is that INSTALL_MASK is NOT a hack.
> 
> Sure it is. It's a hack and remains a hack until there's a way of using
> it without risk of breakage.

LOL.  Better turn off that computer then.  By your definition it's a 
hack.  Or at least remove anything gentoo related from it.  That's a hack 
too.  Oh, and that stove and microwave, better throw them away too, 
because leave something cooking too long and... FIRE!  So they're hacks 
too.

You can go back to your tool-less pre-caveman existence if you like.  
I'll keep my "hacks" of tools, thank you very much! =:^)

-- 
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

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

[Tom Wijsman]

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

On Tue, 21 May 2013 21:37:25 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> [snip] FIRE! [snip] "hacks" of tools, thank you very much! =:^)

Glad you like it! Something that breaks isn't a solution though...

> It's a specifically designed part of the whole gentoo support of
> choice system you mention.

I wouldn't call something that's added to our red herring (make.conf) as
an afterthought "designed", but rather a lack of better approaches.

In the Portage tree we could avoid users from having to mask files,
because that could break their system anyway; eg. Go mask some typical
files [1], you'll end up breaking package compilations in the long run
as they need these files installed on your system.

In Portage the /etc/package.* files are a good example, more advanced
include / exclude file masking in the same way would certainly be a
benefit and some kind of base / profile forced install unmask too.

In other Package managers, I assume this madness isn't supported.

In its current state, it certainly has its use cases; though it is
often misused by unaware users that don't know what removal of certain
files has as a consequence, that means it can do more bad than good...

 [1]: http://forums.gentoo.org/viewtopic-t-670094.html
      First INSTALL_MASK I came across searching for it online,
      particularly masking *.h, *.pc and Makefile* are very bad ideas.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Duncan]

Tom Wijsman posted on Wed, 22 May 2013 00:52:15 +0200 as excerpted:

> In the Portage tree we could avoid users from having to mask files,
> because that could break their system anyway; eg. Go mask some typical
> files [1], you'll end up breaking package compilations in the long run
> as they need these files installed on your system.

And a knife or hammer can be used to murder or commit suicide as well; 
that doesn't mean they're bad tools, it means the user is misusing them.

> In Portage the /etc/package.* files are a good example, more advanced
> include / exclude file masking in the same way would certainly be a
> benefit and some kind of base / profile forced install unmask too.

Not a bad idea.  There's more advanced knives and hammers too, but you 
don't have to procure the most expensive one to do the job.  In some 
cases, even a heavy screwdriver can be used as a hammer, if that's what 
you have in your hand and the hammer's down the ladder in the toolbox.
 
> In other Package managers, I assume this madness isn't supported.

That might be part of why I don't use other PMs...

> In its current state, it certainly has its use cases; though it is often
> misused by unaware users that don't know what removal of certain files
> has as a consequence, that means it can do more bad than good...
> 
>  [1]: http://forums.gentoo.org/viewtopic-t-670094.html
>       First INSTALL_MASK I came across searching for it online,
>       particularly masking *.h, *.pc and Makefile* are very bad ideas.


Did you read the use case?  He is (was, that was 2008) doing the builds 
for his 2GB drive netbook on different build system, then doing binpkg 
installs on the netbook.  In that case, INSTALL_MASKING those filetypes 
for installation to the netbook, where he has no intention of doing any 
building anyway, makes quite a lot of sense.

In fact, I have a netbook (tho it has a much larger 100+ gig drive) and 
could use the idea myself (altho currently I don't run a PM at all on the 
netbook, instead rsyncing from the build image on the main machine, so 
I'd have to modify his use case... or mine... somewhat).

As for people misusing the available tools, gentoo has always taken the 
position that we make the tools available and document how to use them, 
but we aren't a babysitting or handholding distro, and if handholding is 
what people want/need, they better look elsewhere as gentoo's simply not 
in that market, and doesn't pretend to be.

-- 
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

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

[Tom Wijsman]

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

On Wed, 22 May 2013 03:06:05 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> And a knife or hammer can be used to murder or commit suicide as
> well; that doesn't mean they're bad tools, it means the user is
> misusing them.

The amount of users misusing a knife or hammer is much lower than the
amount of users misusing INSTALL_MASK. And even if you want to use it
as an example, murdering is only bad when you consider it to be bad.

Anyhow, the knife and hammer aren't the best tools around to do it as
your target will have a high chance of surviving. Unless you target
people that don't defend themselves, all you make is a few scratches.

> There's more advanced knives and hammers too, but you don't have to
> procure the most expensive one to do the job.

You do, because better tools cost more effort.

> In some cases, even a heavy screwdriver can be used as a hammer, if
> that's what you have in your hand and the hammer's down the ladder in
> the toolbox.

It's this kind of lazyness that ends up breaking things.

> > In other Package managers, I assume this madness isn't supported.
> 
> That might be part of why I don't use other PMs...

But other users do, because Portage isn't perfect.
 
> > In its current state, it certainly has its use cases; though it is
> > often misused by unaware users that don't know what removal of
> > certain files has as a consequence, that means it can do more bad
> > than good...
> > 
> >  [1]: http://forums.gentoo.org/viewtopic-t-670094.html
> >       First INSTALL_MASK I came across searching for it online,
> >       particularly masking *.h, *.pc and Makefile* are very bad
> > ideas.
> 
> Did you read the use case?  He is (was, that was 2008) doing the
> builds for his 2GB drive netbook on different build system, then
> doing binpkg installs on the netbook.  In that case, INSTALL_MASKING
> those filetypes for installation to the netbook, where he has no
> intention of doing any building anyway, makes quite a lot of sense.

A good lesson is that people don't actually read all that stuff, those
that are looking for values for INSTALL_MASK will often just try it for
themselves only to see these dangerous values fail and start bothering
them. Or they may not know it's because of their INSTALL_MASK that they
need to reinstall their system some time later.

Historically, ricing other settings like the CFLAGS in make.conf is a
quite good example of why this file is a red herring; it took quite
some time for the concept of SAFE CFLAGS to get some attention. That's
why SAFE INSTALL MASKS is amongst one of the suggestions I made in the
earlier reply; people on an embedded profile could mask these files,
other people cannot unless they _explicitly_ unmask the ability to mask.

> In fact, I have a netbook (tho it has a much larger 100+ gig drive)
> and could use the idea myself (altho currently I don't run a PM at
> all on the netbook, instead rsyncing from the build image on the main
> machine, so I'd have to modify his use case... or mine... somewhat).

Not running a PM makes this paragraph irrelevant to this discussion.

> As for people misusing the available tools, gentoo has always taken
> the position that we make the tools available and document how to use
> them, but we aren't a babysitting or handholding distro, and if
> handholding is what people want/need, they better look elsewhere as
> gentoo's simply not in that market, and doesn't pretend to be. 

We do babysitting / handholding where we can, the _right_ amount of it.

Not bringing out news or supporting people with the udev upgrade, that
would've cost us people; not working on options that make systemd work,
that would've cost us people. Not pointing to solutions for the recent
automake errors / genkernel blocker, that would've cost us people.

Let's not sacrifice part of our user base by taking a wrong decision;
developing a distro goes much further than "let's just use this hack",
until multiple people agree a hack to be the best short term solution.

Go consistently make the worst tools available, we'll talk again then.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Rich Freeman]

On Wed, May 22, 2013 at 4:46 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> The amount of users misusing a knife or hammer is much lower than the
> amount of users misusing INSTALL_MASK.

Agreed.  A typical user would almost never need to use INSTALL_MASK.
If they're using it, they're probably doing something wrong.

If you want to not install unit files, I'd say you're probably doing
something wrong, but if you want to do that anyway, INSTALL_MASK is in
fact the most appropriate tool for the job.  Ditto if you don't want
to install init.d scripts.

>
> Let's not sacrifice part of our user base by taking a wrong decision;
> developing a distro goes much further than "let's just use this hack",
> until multiple people agree a hack to be the best short term solution.

Few people NEED to INSTALL_MASK systemd units.  For those who don't
care about a few hundred inodes, just use the system and don't worry
about this.  For those who go nuts over it, use the feature.  You get
to keep the pieces if you use it wrong.

If you don't want to break your system, just set the desktop profile,
don't touch your flags, and just emerge what you want.  Your system
will work just fine.

Rich

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

[Luca Barbato]

On 05/21/2013 09:03 AM, Alan McKinnon wrote:
> On 21/05/2013 05:03, Daniel Campbell wrote:
>> That's missing the point. If you don't run systemd, having unit files is
>> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
>> like a hack instead of something more robust. Why include systemd unit
>> files (by default, with no systemd USE flag, thanks to the council...)
>> on a system that's not using it? 154 files isn't negligible unless
>> you're flippant with your system and don't care about bloat. Unused
>> software sitting around *is* a waste of disk-space.
>>
>> Some people (like myself) came to Gentoo to avoid putting systemd on
>> their systems and to make use of the great choice that Gentoo allows.
>> This push to make systemd a "first level citizen" or whatever reeks of
>> marketing. If there is desire among users for unit files, they can
>> contact upstream or maintain their own set of unit files. It's not like
>> they're hard to write.
>>
> 
> <amused long-term user chipping in>
> 
> This is such a weak argument it's quite laughable.
> 
> I don't like gnu info files. Neither me nor anyone I know can figure out
> how to drive info. So, let's rip all the info files out of every
> package; leaving the 3 users who do know info free to grab their copies
> from upstream. I mean it's not like it's hard or anything, and info
> files are easy to write.

check the FEATURES variable and be surprise =) (from man make.conf)

              nodoc  Do not install doc files (/usr/share/doc).

              noinfo Do not install info pages.

              noman  Do not install manpages.

Adding a nounits norunscript and such might work and had been proposed.

lu

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

[Ciaran McCreesh]

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

On Tue, 21 May 2013 21:37:25 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> Ciaran McCreesh posted on Tue, 21 May 2013 14:50:04 +0100 as
> excerpted:
> > On Tue, 21 May 2013 04:45:12 +0000 (UTC)
> > Duncan <1i5t5.duncan@cox.net> wrote:
> >> But the point you're missing is that INSTALL_MASK is NOT a hack.
> > 
> > Sure it is. It's a hack and remains a hack until there's a way of
> > using it without risk of breakage.
> 
> LOL.  Better turn off that computer then.  By your definition it's a 
> hack.  Or at least remove anything gentoo related from it.  That's a
> hack too.  Oh, and that stove and microwave, better throw them away
> too, because leave something cooking too long and... FIRE!  So
> they're hacks too.

That's nonsense, and you know it. There is a big difference between a
carefully designed feature that only breaks if someone screws up, and
something which breaks arbitrarily with no warning. One of the things
about working with computers is that, if something breaks, it's because
someone screwed up. If you really think you can't use your computer
without something breaking, you should carefully consider who is doing
the screwing up.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michał Górny]

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

On Wed, 22 May 2013 17:21:40 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 05/21/2013 09:03 AM, Alan McKinnon wrote:
> > On 21/05/2013 05:03, Daniel Campbell wrote:
> >> That's missing the point. If you don't run systemd, having unit files is
> >> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
> >> like a hack instead of something more robust. Why include systemd unit
> >> files (by default, with no systemd USE flag, thanks to the council...)
> >> on a system that's not using it? 154 files isn't negligible unless
> >> you're flippant with your system and don't care about bloat. Unused
> >> software sitting around *is* a waste of disk-space.
> >>
> >> Some people (like myself) came to Gentoo to avoid putting systemd on
> >> their systems and to make use of the great choice that Gentoo allows.
> >> This push to make systemd a "first level citizen" or whatever reeks of
> >> marketing. If there is desire among users for unit files, they can
> >> contact upstream or maintain their own set of unit files. It's not like
> >> they're hard to write.
> >>
> > 
> > <amused long-term user chipping in>
> > 
> > This is such a weak argument it's quite laughable.
> > 
> > I don't like gnu info files. Neither me nor anyone I know can figure out
> > how to drive info. So, let's rip all the info files out of every
> > package; leaving the 3 users who do know info free to grab their copies
> > from upstream. I mean it's not like it's hard or anything, and info
> > files are easy to write.
> 
> check the FEATURES variable and be surprise =) (from man make.conf)
> 
>               nodoc  Do not install doc files (/usr/share/doc).
> 
>               noinfo Do not install info pages.
> 
>               noman  Do not install manpages.
> 
> Adding a nounits norunscript and such might work and had been proposed.

Yet it's just redundant and a more specific form of INSTALL_MASK.
Without the ability to e.g. rebuild packages which were installing
given files.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Zac Medico]

On 05/22/2013 08:21 AM, Luca Barbato wrote:
> check the FEATURES variable and be surprise =) (from man make.conf)
>
>                nodoc  Do not install doc files (/usr/share/doc).
>
>                noinfo Do not install info pages.
>
>                noman  Do not install manpages.
>
> Adding a nounits norunscript and such might work and had been proposed.

It will require portage to be able to predict where the units are 
installed, and also be able to avoid accidentally wiping out anything 
else that may be installed nearby. The prediction issue also comes up in 
this bug which requests a 'dounit' ebuild helper:

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

Maybe the package manager should query the unit location from pkg-config?
-- 
Thanks,
Zac

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

[Mike Gilbert]

On Wed, May 22, 2013 at 2:42 PM, Zac Medico <zmedico@gentoo.org> wrote:
> On 05/22/2013 08:21 AM, Luca Barbato wrote:
>>
>> check the FEATURES variable and be surprise =) (from man make.conf)
>>
>>                nodoc  Do not install doc files (/usr/share/doc).
>>
>>                noinfo Do not install info pages.
>>
>>                noman  Do not install manpages.
>>
>> Adding a nounits norunscript and such might work and had been proposed.
>
>
> It will require portage to be able to predict where the units are installed,
> and also be able to avoid accidentally wiping out anything else that may be
> installed nearby. The prediction issue also comes up in this bug which
> requests a 'dounit' ebuild helper:
>
>   https://bugs.gentoo.org/show_bug.cgi?id=469086
>
> Maybe the package manager should query the unit location from pkg-config?

That sounds reasonable to me.

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

[Daniel Campbell]

On 05/20/2013 10:34 PM, Canek Peláez Valdés wrote:
> On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell <dlcampbell@gmx.com> wrote:
>> On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote:
>>> On Sun, May 19, 2013 at 9:34 AM, Peter Stuge <peter@stuge.se> wrote:
>>>> J. Roeleveld wrote:
>>>>> I don't see how this will avoid the issue of a limited amount of
>>>>> inodes.
>>>>> That is what I usually run out of before the disk is full when
>>>>> storing lots of smaller files.
>>>>
>>>> I guess the number of unit files is on the order of hundreds
>>>
>>> (Sorry, sent email before it was ready).
>>>
>>> Laptop running full GNOME:
>>>
>>> # find /usr/lib/systemd/system -type f | wc
>>>     154     154    7012
>>>
>>> Server running Apache+MySQL+Mailman+Squid+Other services:
>>>
>>> # find /usr/lib/systemd/system -type f | wc
>>>     121     121    5560
>>>
>>> And as you said, you can always use INSTALL_MASK. If 154 files are
>>> going to deplete your inodes, I think your problem lies somewhere
>>> else.
>>>
>>> Regards.
>>> --
>>> Canek Peláez Valdés
>>> Posgrado en Ciencia e Ingeniería de la Computación
>>> Universidad Nacional Autónoma de México
>>>
>>
>> That's missing the point. If you don't run systemd, having unit files is
>> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
>> like a hack instead of something more robust. Why include systemd unit
>> files (by default, with no systemd USE flag, thanks to the council...)
>> on a system that's not using it? 154 files isn't negligible unless
>> you're flippant with your system and don't care about bloat. Unused
>> software sitting around *is* a waste of disk-space.
> 
> Unit files are not software; they are data.
> 
> And I believe you are the one missing the point. I don't run OpenRC; I
> don't need no files in /etc/init.d. But you don't see me (nor any
> other systemd user) complaining about pointless scripts in
> /etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with my
> life.
> 
> Non-systemd users should do the same for files under /usr/lib/systemd,
> if they really are that worried about systemd "infecting" their
> systems. Complaining about a council-decided policy (and, I believe,
> backed up by the developers that matter, including the OpenRC
> maintainers) is just beating on a dead horse.
> 
> Get over it.
> 
>> Some people (like myself) came to Gentoo to avoid putting systemd on
>> their systems and to make use of the great choice that Gentoo allows.
>> This push to make systemd a "first level citizen" or whatever reeks of
>> marketing.
> 
> If Gentoo is about choice, then systemd is one of those choices. And
> systemd will become a first class citizen inside Gentoo, like it or
> not. Support for it has been getting better and better, and more and
> more Gentoo users are running with systemd.
> 
> If  some fundamentalists users don't want even one file in their
> systems with "systemd" on their paths, they can install eudev/mdev,
> put the necessary directories in INSTALL_MASK, and do the extra work.
> If some other fundamentalists users (like myself) don't want even one
> OpenRC related file on our systems, we can create an overlay to remove
> the dependency of baselayout on OpenRC, put /etc/init.d in
> INSTALL_MASK, and do the extra work.
> 
> Neither case covers the average systemd/OpenRC user, who doesn't care
> about a few scattered files in /etc/init.d nor /usr/lib/systemd, and
> just want to run her machine with the init system of her choice. If
> Gentoo is really about choice.
> 
>> If there is desire among users for unit files, they can
>> contact upstream or maintain their own set of unit files. It's not like
>> they're hard to write.
> 
> So, Gentoo is about choice, but only for the choices you agree with. Great.
> 
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
> 

It seems that I've stepped on a few toes in calling INSTALL_MASK a hack.
Hacks aren't necessarily bad; if anything it shows that there's interest
in supporting something but perhaps not enough time or manpower to
implement a more robust solution. If adding one or two directories to
that variable will nuke any unit files, consider me happy.

systemd is certainly a choice, but it is no more deserving of
consideration than any other init system. I don't see anyone calling for
runit to be a 'first level citizen'. I wonder why that is. Again, if
INSTALL_MASKing openrc dirs will get rid of init scripts for systemd
users, then perhaps INSTALL_MASK is the best we have for now and should
make use of it. I never said that it wasn't suitable to use.

As for "complaining" about policy, what is the proper thing to do in a
situation where someone questions the reasoning behind a decision? Are
there links somewhere on Gentoo's website that outline the process for
each important decision that the council's made? I think it'd be
valuable information for people and keep individuals like you from
telling others to "get over it" without any explanation whatsoever.
That's not communication, that's prescription.

I'm curious as to why you consider users who want to save disk space
(openrc or systemd, or other packages, it doesn't matter) as
fundamentalists.

I do not consider Gentoo to be only about my own choices, but as a user,
who else's choices am I going to consider when I administer my system?
I'm happy for any new choices as long as they don't step on mine. I
think that's fair.

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

[Canek Peláez Valdés]

On Wed, May 22, 2013 at 9:39 PM, Daniel Campbell <dlcampbell@gmx.com> wrote:
> On 05/20/2013 10:34 PM, Canek Peláez Valdés wrote:
>> On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell <dlcampbell@gmx.com> wrote:
>>> On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote:
>>>> On Sun, May 19, 2013 at 9:34 AM, Peter Stuge <peter@stuge.se> wrote:
>>>>> J. Roeleveld wrote:
>>>>>> I don't see how this will avoid the issue of a limited amount of
>>>>>> inodes.
>>>>>> That is what I usually run out of before the disk is full when
>>>>>> storing lots of smaller files.
>>>>>
>>>>> I guess the number of unit files is on the order of hundreds
>>>>
>>>> (Sorry, sent email before it was ready).
>>>>
>>>> Laptop running full GNOME:
>>>>
>>>> # find /usr/lib/systemd/system -type f | wc
>>>>     154     154    7012
>>>>
>>>> Server running Apache+MySQL+Mailman+Squid+Other services:
>>>>
>>>> # find /usr/lib/systemd/system -type f | wc
>>>>     121     121    5560
>>>>
>>>> And as you said, you can always use INSTALL_MASK. If 154 files are
>>>> going to deplete your inodes, I think your problem lies somewhere
>>>> else.
>>>>
>>>> Regards.
>>>> --
>>>> Canek Peláez Valdés
>>>> Posgrado en Ciencia e Ingeniería de la Computación
>>>> Universidad Nacional Autónoma de México
>>>>
>>>
>>> That's missing the point. If you don't run systemd, having unit files is
>>> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
>>> like a hack instead of something more robust. Why include systemd unit
>>> files (by default, with no systemd USE flag, thanks to the council...)
>>> on a system that's not using it? 154 files isn't negligible unless
>>> you're flippant with your system and don't care about bloat. Unused
>>> software sitting around *is* a waste of disk-space.
>>
>> Unit files are not software; they are data.
>>
>> And I believe you are the one missing the point. I don't run OpenRC; I
>> don't need no files in /etc/init.d. But you don't see me (nor any
>> other systemd user) complaining about pointless scripts in
>> /etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with my
>> life.
>>
>> Non-systemd users should do the same for files under /usr/lib/systemd,
>> if they really are that worried about systemd "infecting" their
>> systems. Complaining about a council-decided policy (and, I believe,
>> backed up by the developers that matter, including the OpenRC
>> maintainers) is just beating on a dead horse.
>>
>> Get over it.
>>
>>> Some people (like myself) came to Gentoo to avoid putting systemd on
>>> their systems and to make use of the great choice that Gentoo allows.
>>> This push to make systemd a "first level citizen" or whatever reeks of
>>> marketing.
>>
>> If Gentoo is about choice, then systemd is one of those choices. And
>> systemd will become a first class citizen inside Gentoo, like it or
>> not. Support for it has been getting better and better, and more and
>> more Gentoo users are running with systemd.
>>
>> If  some fundamentalists users don't want even one file in their
>> systems with "systemd" on their paths, they can install eudev/mdev,
>> put the necessary directories in INSTALL_MASK, and do the extra work.
>> If some other fundamentalists users (like myself) don't want even one
>> OpenRC related file on our systems, we can create an overlay to remove
>> the dependency of baselayout on OpenRC, put /etc/init.d in
>> INSTALL_MASK, and do the extra work.
>>
>> Neither case covers the average systemd/OpenRC user, who doesn't care
>> about a few scattered files in /etc/init.d nor /usr/lib/systemd, and
>> just want to run her machine with the init system of her choice. If
>> Gentoo is really about choice.
>>
>>> If there is desire among users for unit files, they can
>>> contact upstream or maintain their own set of unit files. It's not like
>>> they're hard to write.
>>
>> So, Gentoo is about choice, but only for the choices you agree with. Great.
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>> Posgrado en Ciencia e Ingeniería de la Computación
>> Universidad Nacional Autónoma de México
>>
>
> It seems that I've stepped on a few toes in calling INSTALL_MASK a hack.
> Hacks aren't necessarily bad; if anything it shows that there's interest
> in supporting something but perhaps not enough time or manpower to
> implement a more robust solution. If adding one or two directories to
> that variable will nuke any unit files, consider me happy.

As I was, when I used to put /etc/init.d in INSTALL_MASK.

> systemd is certainly a choice, but it is no more deserving of
> consideration than any other init system. I don't see anyone calling for
> runit to be a 'first level citizen'. I wonder why that is.

Probably because is used by a really small number of users, contrary to systemd

> Again, if
> INSTALL_MASKing openrc dirs will get rid of init scripts for systemd
> users, then perhaps INSTALL_MASK is the best we have for now and should
> make use of it. I never said that it wasn't suitable to use.

Then we agree.

> As for "complaining" about policy, what is the proper thing to do in a
> situation where someone questions the reasoning behind a decision?

Contribute?

> Are
> there links somewhere on Gentoo's website that outline the process for
> each important decision that the council's made?

The Council meetings logs are in the Council project page:

http://www.gentoo.org/proj/en/council/
http://www.gentoo.org/proj/en/council/#doc_chap6

> I think it'd be
> valuable information for people and keep individuals like you from
> telling others to "get over it" without any explanation whatsoever.
> That's not communication, that's prescription.

I think I gave an explanation when I said "Complaining about a
council-decided policy (and, I believe, backed up by the developers
that matter, including the OpenRC maintainers) is just beating on a
dead horse." The important thing being that the ones writing the code
(including the OpenRC maintainer) already made their choice.

> I'm curious as to why you consider users who want to save disk space
> (openrc or systemd, or other packages, it doesn't matter) as
> fundamentalists.

Because wanting to eradicate some dozens of files that take not even
one megabyte (combined!) is, in my (updated) view, fundamentalist.

When I wrote the overlay to get rid of OpenRC it was because (back
then, a couple of years ago), some udev rules sometimes would try to
call scripts in /etc/init.d, and then they would try to start all of
OpenRC's services, slowing down (sometimes for close to a minute) the
booting time. Now the situation has improved greatly, and systemd on
Gentoo works great; I would even venture to say that works better than
in Fedora. Now, thanks to the work of people like Fabio Erculiani,
both init systems can be installed in parallel without stepping in
each other toes, and at boot time you can decide which one to use.

I recently converted a server from OpenRC to systemd, and it was the
first time I didn't use my overlay. The switch was completely
painless, and I decided that putting /etc/init.d in INSTALL_MASK was
kinda stupid. It makes no sense (I believe, now) to remove  51 files
that utilize 232K just so the server is "100% OpenRC-free". I think I
should be able to uninstall OpenRC (and work is progressing in that
direction), but I no longer care about files in /etc/init.d.

I got over it.

> I do not consider Gentoo to be only about my own choices, but as a user,
> who else's choices am I going to consider when I administer my system?

Who took away any choice from you?

> I'm happy for any new choices as long as they don't step on mine. I
> think that's fair.

What choices of yours were stepped on?

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

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

[Walter Dnes]

On Wed, May 22, 2013 at 11:42:08AM -0700, Zac Medico wrote

> It will require portage to be able to predict where the units are 
> installed, and also be able to avoid accidentally wiping out anything 
> else that may be installed nearby. The prediction issue also comes up in 
> this bug which requests a 'dounit' ebuild helper:
> 
>    https://bugs.gentoo.org/show_bug.cgi?id=469086
> 
> Maybe the package manager should query the unit location from pkg-config?

  I think this is the wrong algorithm... i.e. asking where files of type
"X" are installed, and wreaking havoc in in that location.  I think that
it would be more robust for the installer to decide which files are of
type "X", and not install them in the first place.  This approach does
not risk wiping files from another program in the same directory.  And
preventative action is generally better than cleaning up after the fact.

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

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

[Duncan]

Ciaran McCreesh posted on Wed, 22 May 2013 16:24:05 +0100 as excerpted:

> On Tue, 21 May 2013 21:37:25 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>> Ciaran McCreesh posted on Tue, 21 May 2013 14:50:04 +0100 as
>> excerpted:
>> > On Tue, 21 May 2013 04:45:12 +0000 (UTC)
>> > Duncan <1i5t5.duncan@cox.net> wrote:
>> >> But the point you're missing is that INSTALL_MASK is NOT a hack.
>> > 
>> > Sure it is. It's a hack and remains a hack until there's a way of
>> > using it without risk of breakage.
>> 
>> LOL.  Better turn off that computer then.  By your definition it's a 
>> hack.  Or at least remove anything gentoo related from it.  That's a
>> hack too.  Oh, and that stove and microwave, better throw them away
>> too, because leave something cooking too long and... FIRE!  So
>> they're hacks too.
> 
> That's nonsense, and you know it. There is a big difference between a
> carefully designed feature that only breaks if someone screws up, and
> something which breaks arbitrarily with no warning. One of the things
> about working with computers is that, if something breaks, it's because
> someone screwed up. If you really think you can't use your computer
> without something breaking, you should carefully consider who is doing
> the screwing up.

That's the point.  It *IS* possible to use INSTALL_MASK sanely, without 
something breaking.  Applying your exact phrasing to the topic at hand: 
"If you really think[1] you can't use INSTALL_MASK without something 
breaking, you should carefully consider who is doing the screwing up."

[1] Think:  Or for that matter, demonstrate to yourself and others.

-- 
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

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

[Alan McKinnon]

On 22/05/2013 23:39, Daniel Campbell wrote:
> I do not consider Gentoo to be only about my own choices, but as a user,
> who else's choices am I going to consider when I administer my system?
> I'm happy for any new choices as long as they don't step on mine. I
> think that's fair.

Your choices are necessarily constrained by the fact that other people
also have choices, and those people use a copy of the same machinery you
use to implement their choices.

You do not operate in a vacuum, and you cannot consider just your own
choices and get a sane result - Godel proved that this cannot happen in
this universe, in much the same way you cannot multiple two and three
and get nine.

Now, you cannot know what choices I've made here on my systems, but you
do know that I have choices and you must consider that fact when making
your choices. This has many side-effects, but the most common is that
often you have to give a little to get a lot. In the case of systemd -
people like Canek have the choice to use it, and to give him that choice
you pretty much have to tolerate that all our machines are going to get
unit files. That's the bit where you give a little.

It works in reverse too. If you want KDE you get .desktop files and so
does everyone else, and they too must give a little.

If the generic machinery (aka package managers) that deals with this
stuff doesn't quite cut the mustard as you would like, you still retain
the ultimate choice:

rm

or it's expedient cousin

INSTALL_MASK

-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Michał Górny]

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

On Wed, 22 May 2013 16:39:25 -0500
Daniel Campbell <dlcampbell@gmx.com> wrote:

> I'm curious as to why you consider users who want to save disk space
> (openrc or systemd, or other packages, it doesn't matter) as
> fundamentalists.

I'd call them using other words but I didn't want to be that inpolite.
Seriously, there are bigger problems in the world than a few text
files. And much bigger useless space consumers which you don't even
notice because they don't have the 'systemd' name on them.

If you care about disk space, then find the biggest consumers and try
to work on them. Otherwise, you're just picking. And that's close to
fundamentalism.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Tom Wijsman]

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

On Thu, 23 May 2013 05:30:25 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> That's the point.  It *IS* possible to use INSTALL_MASK sanely,
> without something breaking.

Nobody said it isn't, I agree hacks can be used without breaking
things; the point is that that doesn't make it a good idea in general.

> Applying your exact phrasing to the topic at hand: "If you really
> think[1] you can't use INSTALL_MASK without something breaking, you
> should carefully consider who is doing the screwing up."

If you really think[1] you need INSTALL_MASK for a few small files when
there are much larger consumers around, you should carefully consider
whether what you are doing is the right thing. ("OMG systemd units!")

> [1] Think:  Or for that matter, demonstrate to yourself and others.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Duncan]

Tom Wijsman posted on Thu, 23 May 2013 08:57:02 +0200 as excerpted:

> If you really think[1] you need INSTALL_MASK for a few small files when
> there are much larger consumers around, you should carefully consider
> whether what you are doing is the right thing. ("OMG systemd units!")
> 
>> [1] Think:  Or for that matter, demonstrate to yourself and others.

Definitely agreed, there.  IMO that whole issue's a tempest in a teapot, 
as the saying goes, not only because it's a trivial use of space, but 
because the solution for any gentooer that actually cares is equally 
trivial.

That's part of what gentoo is all about, having the tools available to 
simply do things like this for those who care to (see the whole Larry the 
Cow thing), which we do... as a major bullet point of what makes us 
gentoo. =:^)

-- 
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

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

[Daniel Campbell]

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

On 05/23/2013 01:41 AM, Michał Górny wrote:
> On Wed, 22 May 2013 16:39:25 -0500 Daniel Campbell 
> <dlcampbell@gmx.com> wrote:
> 
>> I'm curious as to why you consider users who want to save disk 
>> space (openrc or systemd, or other packages, it doesn't matter) 
>> as fundamentalists.
> 
> I'd call them using other words but I didn't want to be that 
> inpolite. Seriously, there are bigger problems in the world than a 
> few text files. And much bigger useless space consumers which you 
> don't even notice because they don't have the 'systemd' name on 
> them.
> 
> If you care about disk space, then find the biggest consumers and 
> try to work on them. Otherwise, you're just picking. And that's 
> close to fundamentalism.
> 

I can't speak for others who wish to rid their systems of systemd, but
personally I look for any excessive use of space on my HDD, despite it
being rather large. Since you brought it up, which packages can you
think of that most or all Gentoo boxes will have that take up more
considerable amounts of files or disk space? I'm honestly interested
in *anything* that lowers the disk usage of my OSes; to a point,
anyway. Supporting X or Y codec or feature in the kernel would be more
important than saving 50kB in the kernel binary, for instance.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRnc0WAAoJEJUrb08JgYgH8I0H/RqmDrgkexeLCaBB2RDXKyjv
EAZeVQvjNuxzTJz5Qr+CNHgpAk58YCZVcH+IBspD3Ks1DatKzyoSxuwwG70lfDmX
k/Rp9T+YL/gZnC3Ey6x/ScAwZIDlDbbZO3xwOt+3fHZEhiCE4IFEsCiaWCwEGHV1
NrROzDRBICYc9KePAtksqvYEovu8ex2JCAbthHhDb7fKvr3TqWCBzWtbSMVr0x9k
ZWliahhmEx7IjZ65/yvv/AM2JYzLwaM1hwQxYUX+myTK5YFjMAaMLMZrEgiWp6KZ
a8R0sW7SqbBlbP2z7nJjCrlggDYqMMF4Mv1x7uT0QPiiRxq32+FHcJinwecTHS8=
=sOIU
-----END PGP SIGNATURE-----

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

[Tom Wijsman]

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

On Thu, 23 May 2013 03:02:30 -0500
Daniel Campbell <dlcampbell@gmx.com> wrote:

> I can't speak for others who wish to rid their systems of systemd, but
> personally I look for any excessive use of space on my HDD, despite it
> being rather large. Since you brought it up, which packages can you
> think of that most or all Gentoo boxes will have that take up more
> considerable amounts of files or disk space? I'm honestly interested
> in *anything* that lowers the disk usage of my OSes; to a point,
> anyway. Supporting X or Y codec or feature in the kernel would be more
> important than saving 50kB in the kernel binary, for instance.

These things are likely documented on websites on the internet, on wikis
related to Gentoo and on our forums; if not, you can always start a new
thread on the Gentoo Forums, a new discussion on social media (Google+,
#gentoo-chat on FreeNode, the gentoo-user ML, ...) or so.

Feel free to ping me by mail if you do so, I'll be happy to help...

If you are an user that wishes to contribute to gentoo-dev, please stay
on topic in the thread you are discussing in as well as with the goal
of the ML; if you think we should implement or document space cleaning
better, then you're always welcome to start a new thread about that.

Thank you in advance.

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJRneV4AAoJEJWyH81tNOV9i8kIAJ8ukPzgwMCFcNVc9u/4PFPh
r3T2bHUNZDK7tZoOtjgdQsiEhwtZGThDaIbNbJ3xvAzqh0gd/mY2qUDBKSZRX8oS
JzFK86ZhjKqwm8TBZH/kXTRx98IgV6XxGmsDaGO0c9Zy0lQOzjhdhcCIpzVQwCa9
tZ51n0YlZQcCmL7ZU66/7Nd9Wrx6M6in9Jik6TSk7DH9ACs6IxTKG2WF1kVShI2m
rd50w//F2ACHHZ0pXWjX9XJmNMOkD+jjHI/yV23GvObXJ8ZqXiicAIAT7G89YtBi
G1ew93E2p9WQ06qIFSMfl/+4yQYTfHFRkSpetTAIkpXfAPruoXNhGmaDmadY+is=
=V7zd
-----END PGP SIGNATURE-----

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

[Michael Orlitzky]

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

On 05/23/2013 04:02 AM, Daniel Campbell wrote:
> 
> 
> I can't speak for others who wish to rid their systems of systemd,
> but personally I look for any excessive use of space on my HDD,
> despite it being rather large. Since you brought it up, which
> packages can you think of that most or all Gentoo boxes will have
> that take up more considerable amounts of files or disk space? I'm
> honestly interested in *anything* that lowers the disk usage of my
> OSes; to a point, anyway. Supporting X or Y codec or feature in the
> kernel would be more important than saving 50kB in the kernel
> binary, for instance.
> 

It's not even that we don't agree with you, it's that you're asking
package and/or PM maintainers to do a bunch of work to save you a few
kilobytes of disk space. Their time is better spent elsewhere, I promise.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRnmuyAAoJEBxJck0inpOizroP/340iUw1ftiVKPh7I1cHFF19
9zBV7nW4hrQ25l0uViwLWtt9GMQ+TJK28cT3ru5/L5cQYIJpAmCpaB8bWGuLx1V3
O1XAtFJ16pu7gU72B7/0lGHIbxpl6qcMt+vKvuSnSQme6NANWadf0i3P3UvddGFS
zB4QSbyyePtnjEGEL1mbN3+nZM58u9c3m0vkYfbY7TahclhH0HX48nc+IJTxReVF
22Z/KC7UaGzsXfJR+BDC0RPH42WTaVGkdytE6yotR5JchnLUxujhShYbfumbJs4g
lRlP46bTlUzPEyriqRhdePsyEELDusACrIPzBK82BNEJP47WuO00kIi78CZ7dgyQ
ix82I2d1UQG7+UFEui+eBroDnAmTIPxOgxsIBYMNTc2pUJmnSqHva7iY8QMkBEvo
LddGMLFpjHj3D2LfM4L+RwZxpz0XRZCtZeDeYRnkXqEuPj7Df9/t+3LV5zljyho7
ppRJtBQvHGpB6G7z3HALyc8XIMXQmDtTBoE+CJms8Ifzd2Hs05Muo05he2C+dr8c
b0zDg/5LqG2XloszqB+1MxZNvL9O8vUpAZS9ZIu/Q8+4UpGXO5yPav42aHIWx+Zi
t4KYd8m9i4Wlusi+o4PCBvW4R0a0aOPJyfExg2eqKNFxMcZ2W+pUFgM2tFiZZC10
Am4B9ySQtlgiYa5Agwg2
=gYkv
-----END PGP SIGNATURE-----

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

[J. Roeleveld]

(Late reply due to busy week, just want to clarify a small detail)

On Sun, May 19, 2013 16:34, Peter Stuge wrote:
> J. Roeleveld wrote:
>> I don't see how this will avoid the issue of a limited amount of
>> inodes.
>> That is what I usually run out of before the disk is full when
>> storing lots of smaller files.
>
> I guess the number of unit files is on the order of hundreds, as long
> as you haven't configured an INSTALL_MASK to avoid installing them.
> (Why haven't you?)
>
> Are you saying that a few hundred inodes more will break many systems?
>
> It doesn't seem very likely to me.

Peter,

I agree, it is not likely, but this was in relation to embedded devices
where diskspace is often at a premium.
I will probably start a new thread on gentoo-user about inodes and
filesystems configuration later this year.

--
Joost

ps. no need to reply to this :)

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

[J. Roeleveld]

On Tue, May 21, 2013 09:03, Alan McKinnon wrote:
> I don't like gnu info files. Neither me nor anyone I know can figure out
> how to drive info.

This reminded me of my experience with info-files. Don't know how long ago
it was that I used them as I find google to be a much more useful
resource.

But you might be interested in the following:

* app-text/info2html
     Available versions:  (2.0) *2.0
        {{vhosts}}
     Homepage:            http://info2html.sourceforge.net/
     Description:         Converts GNU .info files to HTML

I haven't tried it myself yet. (Ignore the "hardmask" part in the output,
that's because the portage-filesystem is not automatically mounted)

--
Joost

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

[Ulrich Mueller]

>>>>> On Fri, 24 May 2013, J Roeleveld wrote:

> This reminded me of my experience with info-files. Don't know how
> long ago it was that I used them as I find google to be a much more
> useful resource.

> But you might be interested in the following:

> * app-text/info2html
>      Available versions:  (2.0) *2.0
>         {{vhosts}}
>      Homepage:            http://info2html.sourceforge.net/
>      Description:         Converts GNU .info files to HTML

> I haven't tried it myself yet.

Usually the result is much better if you start from the Texinfo source
and use texi2any --html (included with sys-apps/texinfo itself) for
conversion.

Ulrich

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

[Olav Vitters]

On Wed, May 15, 2013 at 03:41:31PM +0200, Fabio Erculiani wrote:
> 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).

I'm not aware of GNOME 3.8 having a hard requirement on logind. Could
you please show where that is?

-- 
Regards,
Olav

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

[Chí-Thanh Christopher Nguyễn]

Olav Vitters schrieb:
>> 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).
> I'm not aware of GNOME 3.8 having a hard requirement on logind. Could
> you please show where that is?

The bug report about this issue states to which extent GNOME 3.8 needs
logind, and contains pointers to the relevant commits.
https://bugs.gentoo.org/show_bug.cgi?id=464944


Best regards,
Chí-Thanh Christopher Nguyễn

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

[Olav Vitters]

On Fri, Jun 07, 2013 at 02:04:38PM +0200, Chí-Thanh Christopher Nguyễn wrote:
> Olav Vitters schrieb:
> >> 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).
> > I'm not aware of GNOME 3.8 having a hard requirement on logind. Could
> > you please show where that is?
> 
> The bug report about this issue states to which extent GNOME 3.8 needs
> logind, and contains pointers to the relevant commits.
> https://bugs.gentoo.org/show_bug.cgi?id=464944

That bugreport is regarding an optional dependency for the power
handling. It is correct that Ubuntu will switch from ConsoleKit to
logind, so it does make sense to either maintain ConsoleKit or use
logind. But it still is an optional dependency. I do agree with
https://bugs.gentoo.org/show_bug.cgi?id=464944#c11 (probably easier for
all to just use it, it does not require systemd to be the init).

-- 
Regards,
Olav

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

[Chí-Thanh Christopher Nguyễn]

Olav Vitters schrieb:
>> https://bugs.gentoo.org/show_bug.cgi?id=464944
> That bugreport is regarding an optional dependency for the power
> handling. It is correct that Ubuntu will switch from ConsoleKit to
> logind, so it does make sense to either maintain ConsoleKit or use
> logind. But it still is an optional dependency.

You are correct that it is not a hard dependency in a strict sense.
However, suspend support and session management are not obscure
seldom-used functions. So logind becomes a hard requirement for enough
users which justifies calling it that way.


Best regards,
Chí-Thanh Christopher Nguyễn

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

[Olav Vitters]

On Fri, Jun 07, 2013 at 02:34:27PM +0200, Chí-Thanh Christopher Nguyễn wrote:
> Olav Vitters schrieb:
> >> https://bugs.gentoo.org/show_bug.cgi?id=464944
> > That bugreport is regarding an optional dependency for the power
> > handling. It is correct that Ubuntu will switch from ConsoleKit to
> > logind, so it does make sense to either maintain ConsoleKit or use
> > logind. But it still is an optional dependency.
> 
> You are correct that it is not a hard dependency in a strict sense.
> However, suspend support and session management are not obscure
> seldom-used functions. So logind becomes a hard requirement for enough
> users which justifies calling it that way.

You can still use ConsoleKit, why are you saying session management? The
suspend I'm not sure about.

Regarding hard requirment:
You do *not* need systemd to compile GNOME. You do *not* need logind. We
do make use of various APIs and you're encouraged/recommended to use a
few things (either API or e.g. logind).

If it is phrased as "hard requirement" this continues the messages on
this gentoo-dev where it is suggested that things are forced. In
practice we do not have a hard requirement. AFAIK nobody stepped up to
maintain ConsoleKit. Ubuntu would, but they went with logind.

I'd encourage people to actually maintain ConsoleKit. Saying we use
something that's maintained and solved some design issues in ConsoleKit
is a bit easy.

-- 
Regards,
Olav