Mailing List Archive

1 2 3 4 5 6 7  View All
Re: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
-----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: Making systemd more accessible to "normal" users [ In reply to ]
-----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: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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
Re: Making systemd more accessible to "normal" users [ In reply to ]
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
Re: Making systemd more accessible to "normal" users [ In reply to ]
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.
Re: Making systemd more accessible to "normal" users [ In reply to ]
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
Re: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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
Re: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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
Re: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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
Re: Making systemd more accessible to "normal" users [ In reply to ]
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: Making systemd more accessible to "normal" users [ In reply to ]
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 ;))

1 2 3 4 5 6 7  View All