[gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Ben de Groot]

I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing
list, since this discussion doesn't really belong on bugzilla.

Some background copied from the bug report:

(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #17)
> > > (In reply to comment #15)
> > > > (In reply to comment #14)
> > > > > I believe it is time to reconsider this now that systemd support is spread
> > > > > all over the tree.
> > > >
> > > > I don't think so. If upstream ships it, we will install it. Otherwise we
> > > > don't. Most Gentoo devs (as well as users) do not use systemd, nor have it
> > > > installed. I don't think it can be expected of us to test and maintain
> > > > systemd related patches.
> > >
> > > I expect this to change in the future. We can't keep denying that a new init
> > > system exists and we need to at least provide a limited support for it (even
> > > though we can't test it ourselves).
> >
> > WTF man? No, we do not _need_ to add support for an alternative init system
> > that is so aggressively opposed to what we stand for. But since you pushed
> > this change through against my wishes, I will remove myself as maintainer of
> > this package.
> You seem to have ignored all the discussions in -dev where it was agreed to
> install systemd files without even a useflag.

I haven't ignored the discussion. We agreed to install systemd files
IF they are shipped by upstream.

> So really, if you disagree
> this is your problem since the community agreed to do it.

Unless I am mistaken, we did NOT agree anywhere that Gentoo
maintainers MUST add systemd support when upstream does not ship such
files.

And even if a few vocal members want that, that does not constitute
community agreement. As far as I'm concerned, if it is not in the
devmanual, or a council decision, it is not official policy. In that
case individual package maintainers can do as they wish.

> It is also NOT documented anywhere that Gentoo supports *ONLY* openrc.
> Just grep for "systemd_dounit" in the tree and see how many pakcages do that.

So? That does not mean that as package maintainer I have to accept a
patch to support a non-default init system. Some maintainers may
choose to do so, others may choose not to.

> It is very sad to be threatened over and over. If I do something then X
> people will be unhappy. If I do it Y people will be unhappy. So in this case
> I did what we agreed to do in the mailing list.

We did not agree on this. Package maintainers may do as they wish for
their own packages.

I already expressed my opinion twice in that bug report: if upstream
ships a systemd unit file, we will let the ebuild install it. But we
do not have to add a patch to enable systemd support where upstream
does not ship it.

Also, I am not "threatening" anyone. But if you so clearly disregard
my opinion as co-maintainer, then I see no way we can work together on
this.

> You will soon realize that your stance against systemd will make you
> disagree with more developers in the imminent future.

That may be the case, but as long as OpenRC is Gentoo's default, and
we are not forced to add support for systemd where upstream does not,
then we can all continue on our merry way.

It is in the nature of a big open source project like Gentoo that
there will be disagreements. But we can agree to respectfully disagree
and work out some policies that are acceptable for people with
different opinions.


(In reply to comment #22)
> (In reply to comment #19)
> > WTF man? No, we do not _need_ to add support for an alternative init system
> > that is so aggressively opposed to what we stand for.
>
> Eh...
>
>  1) Who is "we"?
>
>  2) What exactly does this "we" people stand for?
>
>  3) Why does "we" stand aggressively opposed to an alternative init system?
>
> If you meant Gentoo, it stands for "... just about any application or need."
> [1] and I don't see why it would be aggressively opposed to an alternative
> init system which some of our users are experiencing a benefit from; apart
> from a rather small group of people that decide to behave strongly opposed
> to it.

The whole paragraph on that page says: "Gentoo is a free operating
system based on either Linux or FreeBSD that can be automatically
optimized and customized for just about any application or need.
Extreme configurability, performance and a top-notch user and
developer community are all hallmarks of the Gentoo experience. "

Systemd is diametrically opposed to the FreeBSD, customization,
extreme configurability, and top-notch developer community aspects of
that. Systemd upstream developers have made it abundantly clear they
are not interested in working with Gentoo developers to see to the
needs of source-based distros. They stand for vertical integration
instead of customization and configurability.

And you misunderstood: it is systemd that is aggressively opposed to
Gentoo. But apparently that doesn't bother some of our developers and
Gentoo is becoming more and more welcoming to it.

> > But since you pushed this change through against my wishes, I will remove myself as maintainer of this package.
>
> If having systemd@g.o (or any other alternative init system, or any other
> developer permitted by them or a higher instance) add just a few characters
> you never need to touch and changing an unit file you don't want is too
> much, then you're just stepping away from the collaborative effort that
> pursues the goal as stated on the about page of Gentoo; we're all in this
> together, don't make hate tear you apart.

I am making a stand for what I believe in. That is not hate. I simply
think that systemd is a bad idea. But if others want to make it work
on Gentoo, that is their time to waste.

For my part, I simply wish to not be forced to add support for it in
packages I maintain.

> Are you going to stop maintaining
> any package alternative init system maintainers and users come nag you on? :(

That is not what this is about. I will simply do the same as I already
did on this bug: refer users to upstream.

But if a co-maintainer pushes through a change that I oppose, then
working together becomes quite difficult. In this case I opted to give
up maintainership.

>  [1]: http://www.gentoo.org/main/en/about.xml
>
> Hope you would reconsider, it isn't hard to CC systemd@g.o and let them add
> or change characters that don't stand in your way; in fact, when I'm bug
> wrangling I've started CC-ing them on any new "systemd unit request" bugs
> such they can help if the maintainer does not have knowledge in the area.

I don't want to do that. And as long as I am not forced to do so, I
will maintain the packages I maintain as I see fit.

> Similarly, I expect in the near future that OpenRC mantainers (and any other
> alternative init system maintainers) will do the same; because really, even
> some of our systemd developers are starting to forget how init files were
> implemented, nor are they able to easily test them.
>
> At least not until we get eselect init sorted out... :)

--
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Michał Górny]

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

On Sun, 26 May 2013 00:14:36 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing
> list, since this discussion doesn't really belong on bugzilla.

Since Bugzilla is down at the moment and it seems not to be mentioned
anywhere in the mail, the package is x11-misc/lightdm.

> Some background copied from the bug report:
> 
> (In reply to comment #21)
> > (In reply to comment #19)
> > > WTF man? No, we do not _need_ to add support for an alternative init system
> > > that is so aggressively opposed to what we stand for. But since you pushed
> > > this change through against my wishes, I will remove myself as maintainer of
> > > this package.
> > You seem to have ignored all the discussions in -dev where it was agreed to
> > install systemd files without even a useflag.
> 
> I haven't ignored the discussion. We agreed to install systemd files
> IF they are shipped by upstream.

Where? I don't even think I've seen a single statement like this on
the late threads.

> > So really, if you disagree
> > this is your problem since the community agreed to do it.
> 
> Unless I am mistaken, we did NOT agree anywhere that Gentoo
> maintainers MUST add systemd support when upstream does not ship such
> files.

We did agree that Gentoo maintainers are not supposed to work on
enabling systemd support if they don't want to. On the other hand, we
also agreed that they shouldn't refuse unit files if anyone else
does the work for them.

> > It is also NOT documented anywhere that Gentoo supports *ONLY* openrc.
> > Just grep for "systemd_dounit" in the tree and see how many pakcages do that.
> 
> So? That does not mean that as package maintainer I have to accept a
> patch to support a non-default init system. Some maintainers may
> choose to do so, others may choose not to.

I'm afraid you're using the word 'patch' incorrectly here. If it was
about a patch, I would agree with you. A patch -- something that
actually modifies package sources or files currently installed by
package. A patch that could mean that our package diverges from
upstream or introduces new bugs for existing users.

A unit file is *not* a patch. It's a file. A file that is incorporated
into the package without modifying its existing contents or behavior
on non-systemd systems. It's not something that could really cause
problems for OpenRC users.

> > It is very sad to be threatened over and over. If I do something then X
> > people will be unhappy. If I do it Y people will be unhappy. So in this case
> > I did what we agreed to do in the mailing list.
> 
> We did not agree on this. Package maintainers may do as they wish for
> their own packages.

Package maintainers are to respect other developers, teams and users.
While their wishes are important, Gentoo rules and policies are even
more important. Much like quite a consistent experience for users.

> The whole paragraph on that page says: "Gentoo is a free operating
> system based on either Linux or FreeBSD that can be automatically
> optimized and customized for just about any application or need.
> Extreme configurability, performance and a top-notch user and
> developer community are all hallmarks of the Gentoo experience. "
> 
> Systemd is diametrically opposed to the FreeBSD, customization,
> extreme configurability, and top-notch developer community aspects of
> that. Systemd upstream developers have made it abundantly clear they
> are not interested in working with Gentoo developers to see to the
> needs of source-based distros. They stand for vertical integration
> instead of customization and configurability.
> 
> And you misunderstood: it is systemd that is aggressively opposed to
> Gentoo. But apparently that doesn't bother some of our developers and
> Gentoo is becoming more and more welcoming to it.

Protecting freedom through taking away the freedom of using systemd?
Makes sense really.

> > > But since you pushed this change through against my wishes, I will remove myself as maintainer of this package.
> >
> > If having systemd@g.o (or any other alternative init system, or any other
> > developer permitted by them or a higher instance) add just a few characters
> > you never need to touch and changing an unit file you don't want is too
> > much, then you're just stepping away from the collaborative effort that
> > pursues the goal as stated on the about page of Gentoo; we're all in this
> > together, don't make hate tear you apart.
> 
> I am making a stand for what I believe in. That is not hate. I simply
> think that systemd is a bad idea. But if others want to make it work
> on Gentoo, that is their time to waste.

Gentoo is not about making stands or running vendettas. 'Sorry, you
have to use Ubuntu because we support the freedom of letting our
developers make stands against X'.

And yet *the others* have actually wasted their time to make it work.
And now you're angry at them for it. And actually wasting people's time
by reviving the same topic. Though you should expect that at this point
most of the developers will simply ignore the topic.

> > Are you going to stop maintaining
> > any package alternative init system maintainers and users come nag you on? :(
> 
> That is not what this is about. I will simply do the same as I already
> did on this bug: refer users to upstream.
> 
> But if a co-maintainer pushes through a change that I oppose, then
> working together becomes quite difficult. In this case I opted to give
> up maintainership.

Yet another stand. No offense but I'm afraid it's quite childish of you.
I don't understand why you're so proud of it. It's a bit like 'Gentoo
will play as I like. If it doesn't, then I will play against Gentoo.
And if that doesn't help, I will resent and slam the door, and then
write to ml about it.'

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Rich Freeman]

On Sat, May 25, 2013 at 12:48 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 26 May 2013 00:14:36 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>> But if a co-maintainer pushes through a change that I oppose, then
>> working together becomes quite difficult. In this case I opted to give
>> up maintainership.
>
> Yet another stand. No offense but I'm afraid it's quite childish of you.
> I don't understand why you're so proud of it. It's a bit like 'Gentoo
> will play as I like. If it doesn't, then I will play against Gentoo.
> And if that doesn't help, I will resent and slam the door, and then
> write to ml about it.'

Honestly, if people want to have that attitude they might as well stop
maintaining anything that installs a daemon.  As a developer you have
NO power to prevent somebody else from co-maintaining, and since those
devs who use systemd are likely to want to have units and they're
willing to do the work, you can expect somebody to show up and add a
unit.

The very nature of Gentoo leads to situations where you'll get
requests from other devs to add support for crazy stuff to your
packages (X32, prefix, init systems, etc).  As long as somebody else
is willing to do the work to maintain it (as a developer or proxy) and
it doesn't hurt conventional users, we should cooperate.

Rich

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
>> Yet another stand. No offense but I'm afraid it's quite childish of you.
>> I don't understand why you're so proud of it. It's a bit like 'Gentoo
>> will play as I like. If it doesn't, then I will play against Gentoo.
>> And if that doesn't help, I will resent and slam the door, and then
>> write to ml about it.'
> 
> Honestly, if people want to have that attitude they might as well stop
> maintaining anything that installs a daemon.  As a developer you have
> NO power to prevent somebody else from co-maintaining, and since those
> devs who use systemd are likely to want to have units and they're
> willing to do the work, you can expect somebody to show up and add a
> unit.

This is why I suggested that in case of uncooperative maintainers and
upstreams, put the systemd unit in an extra package. Like it is done for
selinux policies.

> The very nature of Gentoo leads to situations where you'll get
> requests from other devs to add support for crazy stuff to your
> packages (X32, prefix, init systems, etc).  As long as somebody else
> is willing to do the work to maintain it (as a developer or proxy) and
> it doesn't hurt conventional users, we should cooperate.

With x32, I generally refused to apply the patches to x11 maintained packages
before they had upstream ack first.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Rich Freeman]

On Sat, May 25, 2013 at 4:02 PM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Rich Freeman schrieb:
>>> Yet another stand. No offense but I'm afraid it's quite childish of you.
>>> I don't understand why you're so proud of it. It's a bit like 'Gentoo
>>> will play as I like. If it doesn't, then I will play against Gentoo.
>>> And if that doesn't help, I will resent and slam the door, and then
>>> write to ml about it.'
>>
>> Honestly, if people want to have that attitude they might as well stop
>> maintaining anything that installs a daemon.  As a developer you have
>> NO power to prevent somebody else from co-maintaining, and since those
>> devs who use systemd are likely to want to have units and they're
>> willing to do the work, you can expect somebody to show up and add a
>> unit.
>
> This is why I suggested that in case of uncooperative maintainers and
> upstreams, put the systemd unit in an extra package. Like it is done for
> selinux policies.

In this case the developer adding the unit WAS a maintainer.  Nothing
prevents any dev from adding themself as a maintainer to any package.
My point was just that if people plan to stop maintaining packages
whenever this happens that they'll end up not maintaining many
packages, because it is a trend that will continue.  IMHO it isn't
really important for devs to co-maintain packages to add unit files,
but certainly they can do so. Developers don't own the packages they
maintain.

Splitting unit files into separate packages is just going to make us
look like Debian, with everything with a daemon having 15 packages in
the tree.  Would it make sense to split init.d scripts into a separate
package?

The Council already decided that the appropriate way to handle unit
files was to put them in the package, without a USE flag, and users
could mask them if they didn't want them around.

>
> With x32, I generally refused to apply the patches to x11 maintained packages
> before they had upstream ack first.

x32 generally involved code patches, which involve a lot more risk of
breakage to existing users and in general are a bigger pain since
anytime the underlying source changes you have to re-diff them.  I
could see more of a push for co-maintaining in this case.

Unit files are just files - you stick them in filesdir and in your
ebuild and generally you touch them about as often as you touch init
scripts, which is rare.  If a maintainer does have to touch their init
scripts and it was because a binary was renamed or something, then
they can just ping the systemd team if they want them to update the
units.

In any case, nothing is being appealed here.  Ben basically quit
maintaining a package, which is his right, and the remaining
maintainers are keeping the unit around.  The intent of the systemd
team isn't to get developers to quit, but frankly I don't think we
need to coddle people to the point where threats to quit are a reason
to not add units to packages.  I think Ben is making a mistake, and
frankly if you are trying to resist the systemd takeover then Gentoo
is one of your best options out there so you might as well make sure
the packages you use are well-maintained even if they also work for
systemd users.

Rich

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Michał Górny]

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

On Sat, 25 May 2013 22:02:26 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Rich Freeman schrieb:
> >> Yet another stand. No offense but I'm afraid it's quite childish of you.
> >> I don't understand why you're so proud of it. It's a bit like 'Gentoo
> >> will play as I like. If it doesn't, then I will play against Gentoo.
> >> And if that doesn't help, I will resent and slam the door, and then
> >> write to ml about it.'
> > 
> > Honestly, if people want to have that attitude they might as well stop
> > maintaining anything that installs a daemon.  As a developer you have
> > NO power to prevent somebody else from co-maintaining, and since those
> > devs who use systemd are likely to want to have units and they're
> > willing to do the work, you can expect somebody to show up and add a
> > unit.
> 
> This is why I suggested that in case of uncooperative maintainers and
> upstreams, put the systemd unit in an extra package. Like it is done for
> selinux policies.

If we are to introduce split packages, we should start where doing it
where it actually *makes sense*, rather than doing that to work-around
stubbornness of uncooperative developers.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Luca Barbato]

On 5/25/13 6:48 PM, Michał Górny wrote:
> On Sun, 26 May 2013 00:14:36 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>
>> I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing
>> list, since this discussion doesn't really belong on bugzilla.

Seems that *upstream* had to a bit of work in order to support the 
various bits of systemd (not just the simple unit apparently)

I can understand there is some hurry so somebody could gloat "and even 
Gentoo/Sabayon supports systemd", yet I wouldn't *rush* things and I 
would consider getting something sorted out sanely for everybody.

I doubt I would be treated that nicely if I start spamming all the 
upstreams about supporting runit and demand they to maintain those init 
rules.

We can be kind with difficult upstreams but just up to a point.

That said, I'd rather have set something along the lines of:

- get the eselect init machinery in place

- decide seriously if we want to consider units (and init.d files) as 
manpages and threat them in the same way. This way nosystemd in the 
features would spare you some files as it does for manpages.

- repeat the same treatment for openrc and runit runscripts.

The alternative of having split packages seems a waste of inodes, 
probably in the end having the package manager keep track of this data 
would be better.

lu

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Ben de Groot]

On 26 May 2013 00:48, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 26 May 2013 00:14:36 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>> Unless I am mistaken, we did NOT agree anywhere that Gentoo
>> maintainers MUST add systemd support when upstream does not ship such
>> files.
>
> We did agree that Gentoo maintainers are not supposed to work on
> enabling systemd support if they don't want to.

OK, that sounds good.

> On the other hand, we
> also agreed that they shouldn't refuse unit files if anyone else
> does the work for them.

Where is this policy documented?

>> [...]
>> And you misunderstood: it is systemd that is aggressively opposed to
>> Gentoo. But apparently that doesn't bother some of our developers and
>> Gentoo is becoming more and more welcoming to it.
>
> Protecting freedom through taking away the freedom of using systemd?
> Makes sense really.

That would be similar to the way the GPL protects software freedom.
Does that not make sense to you either?

But it isn't even like that. I'm not taking away anyone's freedom to
use systemd. You can do so if you wish. You can add unit files to your
system by yourself, or use an overlay. There are various ways this
could be realized even within Gentoo.

But you seem to dismiss all of those, and will only be happy by
forcing maintainers to add support to packages they maintain, even if
they believe it is a bad idea.

--
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Michał Górny]

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

On Sun, 26 May 2013 15:23:44 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 26 May 2013 00:48, Michał Górny <mgorny@gentoo.org> wrote:
> > On the other hand, we
> > also agreed that they shouldn't refuse unit files if anyone else
> > does the work for them.
> 
> Where is this policy documented?

Nowhere, I think. I've seen it coming in the late thread, looked common
sense enough to me.

If it is to be documented, I think we should document it in a more
general fashion. To cover all stuff like completions, logrotate and so
on.

> >> [...]
> >> And you misunderstood: it is systemd that is aggressively opposed to
> >> Gentoo. But apparently that doesn't bother some of our developers and
> >> Gentoo is becoming more and more welcoming to it.
> >
> > Protecting freedom through taking away the freedom of using systemd?
> > Makes sense really.
> 
> That would be similar to the way the GPL protects software freedom.
> Does that not make sense to you either?

No. The initial version of that response even used 'FSF' but I've
decided not to flame it.

> But it isn't even like that. I'm not taking away anyone's freedom to
> use systemd. You can do so if you wish. You can add unit files to your
> system by yourself, or use an overlay. There are various ways this
> could be realized even within Gentoo.

You know how fragile that is, don't you?

> But you seem to dismiss all of those, and will only be happy by
> forcing maintainers to add support to packages they maintain, even if
> they believe it is a bad idea.

Do I? As far as I'm concerned, I always kindly asked on IRC or opened
bugs for it.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Rich Freeman]

On Sun, May 26, 2013 at 3:43 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 26 May 2013 15:23:44 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>>
>> Where is this policy documented?
>
> Nowhere, I think. I've seen it coming in the late thread, looked common
> sense enough to me.
>
> If it is to be documented, I think we should document it in a more
> general fashion. To cover all stuff like completions, logrotate and so
> on.
>

As others have already pointed out, we are an organization, not a CPU.
 We can't make EVERYTHING a rule, and devs should act in a cooperative
manner so that this remains the case.

Sure, this can be made into a policy, and if things get out of hand
I'm sure it will be.  I'm not quite sure I see the need yet, as we
don't have an example yet of a maintainer not cooperating with the
systemd team on the installation of init files (in the present example
Ben isn't actually a maintainer, since he stepped down).

If Ben wants to boycott systemd by not maintaining any packages that
support it, that is his choice.  I just suspect that the end result of
that will be that he'll end up not maintaining much of anything.  I'd
hate to see that happen, as it would be a loss for Gentoo.  But,
frankly, letting any one person dictate the direction of the entire
distro by essentially threatening to quit would be worse.

Gentoo is about choice - and the nature of choice is that most of the
choices it supports are ones that you wouldn't personally make.  We do
a reasonably good job letting everybody have their cake and eat it
too.  However, it really isn't an appropriate distro for absolute
purists of almost any kind - it reeks of compromise.  We package
proprietary software (we don't redistribute the copyrighted parts), we
more-or-less run on Windows/OSX, we support that X32 alternate
architecture that some believe has no useful purpose, and so on.

If you really want to influence the battle of the init
implementations, then write code, not emails.  Maybe that is a wrapper
that allows OpenRC to support systemd units.  Maybe that is more
functionality for OpenRC.  Maybe it is something else.  However,
trying to influence things by just spitting into the wind isn't going
to do much but get your face dirty. Sure, devs can quit, but that
isn't just a loss for Gentoo.  Frankly if your main goal in life is to
avoid systemd then you're better off supporting Gentoo which is likely
to support that option nearly forever far better than any other
distro.

Rich

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Ben de Groot]

On 26 May 2013 18:04, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, May 26, 2013 at 3:43 AM, Michał Górny <mgorny@gentoo.org> wrote:
>> On Sun, 26 May 2013 15:23:44 +0800
>> Ben de Groot <yngwin@gentoo.org> wrote:
>>>
>>> Where is this policy documented?
>>
>> Nowhere, I think. I've seen it coming in the late thread, looked common
>> sense enough to me.
>>
>> If it is to be documented, I think we should document it in a more
>> general fashion. To cover all stuff like completions, logrotate and so
>> on.
>>
>
> As others have already pointed out, we are an organization, not a CPU.
>  We can't make EVERYTHING a rule, and devs should act in a cooperative
> manner so that this remains the case.
>
> Sure, this can be made into a policy, and if things get out of hand
> I'm sure it will be.  I'm not quite sure I see the need yet, as we
> don't have an example yet of a maintainer not cooperating with the
> systemd team on the installation of init files (in the present example
> Ben isn't actually a maintainer, since he stepped down).

In packages I maintain, I will not be adding any systemd related files.
All bug reports requesting such additions will be closed as an upstream
matter.

> If Ben wants to boycott systemd by not maintaining any packages that
> support it, that is his choice.  I just suspect that the end result of
> that will be that he'll end up not maintaining much of anything.  I'd
> hate to see that happen, as it would be a loss for Gentoo.  But,
> frankly, letting any one person dictate the direction of the entire
> distro by essentially threatening to quit would be worse.

Gentoo is evolving in directions I do not agree with. I am feeling less
and less at home here. More and more often it seems I am the
minority voice of protest. I am not enjoying this role, and increasingly
the thought arises that I should just get out of people's way and
find another place that is closer to my ideas of what a distro
should be.

> Gentoo is about choice - and the nature of choice is that most of the
> choices it supports are ones that you wouldn't personally make.  We do
> a reasonably good job letting everybody have their cake and eat it
> too.  However, it really isn't an appropriate distro for absolute
> purists of almost any kind - it reeks of compromise.  We package
> proprietary software (we don't redistribute the copyrighted parts), we
> more-or-less run on Windows/OSX, we support that X32 alternate
> architecture that some believe has no useful purpose, and so on.
>
> If you really want to influence the battle of the init
> implementations, then write code, not emails.

I am not a programmer, I am a simple package maintainer.

> Maybe that is a wrapper
> that allows OpenRC to support systemd units.  Maybe that is more
> functionality for OpenRC.  Maybe it is something else.  However,
> trying to influence things by just spitting into the wind isn't going
> to do much but get your face dirty. Sure, devs can quit, but that
> isn't just a loss for Gentoo.  Frankly if your main goal in life is to
> avoid systemd then you're better off supporting Gentoo which is likely
> to support that option nearly forever far better than any other
> distro.

If forcing Gentoo package maintainers to add systemd support
to packages they maintain is your idea of the best option to
avoid systemd, then I respectfully disagree.

Obviously I have better (and more fun) things to do.
--
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Rick "Zero_Chaos" Farina]

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

On 05/26/2013 11:21 AM, Ben de Groot wrote:
> On 26 May 2013 18:04, Rich Freeman <rich0@gentoo.org> wrote:
>> On Sun, May 26, 2013 at 3:43 AM, Michał Górny <mgorny@gentoo.org> wrote:
>>> On Sun, 26 May 2013 15:23:44 +0800
>>> Ben de Groot <yngwin@gentoo.org> wrote:
>>>>
>>>> Where is this policy documented?
>>>
>>> Nowhere, I think. I've seen it coming in the late thread, looked common
>>> sense enough to me.
>>>
>>> If it is to be documented, I think we should document it in a more
>>> general fashion. To cover all stuff like completions, logrotate and so
>>> on.
>>>
>>
>> As others have already pointed out, we are an organization, not a CPU.
>>  We can't make EVERYTHING a rule, and devs should act in a cooperative
>> manner so that this remains the case.
>>
>> Sure, this can be made into a policy, and if things get out of hand
>> I'm sure it will be.  I'm not quite sure I see the need yet, as we
>> don't have an example yet of a maintainer not cooperating with the
>> systemd team on the installation of init files (in the present example
>> Ben isn't actually a maintainer, since he stepped down).
> 
> In packages I maintain, I will not be adding any systemd related files.
> All bug reports requesting such additions will be closed as an upstream
> matter.
> 
>> If Ben wants to boycott systemd by not maintaining any packages that
>> support it, that is his choice.  I just suspect that the end result of
>> that will be that he'll end up not maintaining much of anything.  I'd
>> hate to see that happen, as it would be a loss for Gentoo.  But,
>> frankly, letting any one person dictate the direction of the entire
>> distro by essentially threatening to quit would be worse.
> 
> Gentoo is evolving in directions I do not agree with. I am feeling less
> and less at home here. More and more often it seems I am the
> minority voice of protest. I am not enjoying this role, and increasingly
> the thought arises that I should just get out of people's way and
> find another place that is closer to my ideas of what a distro
> should be.
> 
>> Gentoo is about choice - and the nature of choice is that most of the
>> choices it supports are ones that you wouldn't personally make.  We do
>> a reasonably good job letting everybody have their cake and eat it
>> too.  However, it really isn't an appropriate distro for absolute
>> purists of almost any kind - it reeks of compromise.  We package
>> proprietary software (we don't redistribute the copyrighted parts), we
>> more-or-less run on Windows/OSX, we support that X32 alternate
>> architecture that some believe has no useful purpose, and so on.
>>
>> If you really want to influence the battle of the init
>> implementations, then write code, not emails.
> 
> I am not a programmer, I am a simple package maintainer.
> 
>> Maybe that is a wrapper
>> that allows OpenRC to support systemd units.  Maybe that is more
>> functionality for OpenRC.  Maybe it is something else.  However,
>> trying to influence things by just spitting into the wind isn't going
>> to do much but get your face dirty. Sure, devs can quit, but that
>> isn't just a loss for Gentoo.  Frankly if your main goal in life is to
>> avoid systemd then you're better off supporting Gentoo which is likely
>> to support that option nearly forever far better than any other
>> distro.
> 
> If forcing Gentoo package maintainers to add systemd support
> to packages they maintain is your idea of the best option to
> avoid systemd, then I respectfully disagree.

Perhaps this was covered already, but how exactly did this one file,
added by your co-maintainer, hurt you?  Did it cause additional bugs?
Did it break a working ebuild?  Did it kill your cat?

It would seem to me that the co-maintainer (a person who cares that some
users are interested in systemd enough to add one file to the package)
made the package support a slightly wider range of systems (gentoo is
about choice) and this affects you in exactly no way.

What am I missing here?  Are you just trying to force your will on
others or do you have an actual issue caused by this commit?  It is not
for us developers to force one way on the users, gentoo is supposed to
be about choice, your co-maintainer chose to support systemd, an action
which as far as I can see didn't harm you, and helped some users.  This
has been a very long thread for something I don't get at all.  Please,
seriously, what am I missing here?

- -Zero
> 
> Obviously I have better (and more fun) things to do.
> --
> Cheers,
> 
> Ben | yngwin
> Gentoo developer
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRojUxAAoJEKXdFCfdEflKNXUQAJufMr9HC/7KPLQEWxZG+LH0
kWzrzSjH9I5OLNhTxuVs3IuMupeHL2BPA2oXZV/hj/NKhJid8FXKlNRB9PCuE6qq
ClrnSLuYcdabTNzUmePM+h0CEU5FMkA4Z3GJiT2GtB9fv8CbnjcbuqZAYK4zYupT
B8O61/o/uYCYPEgekqi/vU3xOtPA+wzzwXILV4Kf/YNb9A/z/SyIIsJv4JN2qvSm
UYCe5Q4h7JqUTz0DzL3lVFLhTFdvCWPErP5Okrn1yk8cCL5878ixDkQBm5dL53NH
NNu3EPPhvnljV6Ja1CEAOKmORp2Ry+DDSbYUhx0SK0g/fzo4JQP1TD/IraicQExV
2nFBQL3MKT9It5uzZp0+PsNkfAZMmv2W7Xkx1YNQcj5Zjip5ChdQJqk60uqBUoGs
aenj1CYucki3owKnE4mwb/2Vk6jlZ51uEuJ29GuzYxHXVaonBo1JQNFVw9foDKqV
XQISK7U9HVFD80uH6Gj6bhlWF/CCzw2rX5C1WnGsGr/rk0T87cECS79gPqp2wuA7
gI9amGaK3RaHbYoUqobGSKBH8lY6HQwtF2XHzOILMm39gacVGV6vM4E0m77Ia0Zd
Oze9UfnFMj81qxBCmIyN/YI3BEckc5pMuI/GmW9eW/9EWkIgOI9RPafED492+/GJ
kKbF8ogtV3E3SiTfN22q
=chEY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Matt Turner]

On Sun, May 26, 2013 at 9:15 AM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> Perhaps this was covered already, but how exactly did this one file,
> added by your co-maintainer, hurt you?  Did it cause additional bugs?
> Did it break a working ebuild?  Did it kill your cat?
>
> It would seem to me that the co-maintainer (a person who cares that some
> users are interested in systemd enough to add one file to the package)
> made the package support a slightly wider range of systems (gentoo is
> about choice) and this affects you in exactly no way.
>
> What am I missing here?  Are you just trying to force your will on
> others or do you have an actual issue caused by this commit?  It is not
> for us developers to force one way on the users, gentoo is supposed to
> be about choice, your co-maintainer chose to support systemd, an action
> which as far as I can see didn't harm you, and helped some users.  This
> has been a very long thread for something I don't get at all.  Please,
> seriously, what am I missing here?

Thanks for asking this. After reading the 34 emails in this thread, I
still have this question as well.

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Andreas K. Huettel]

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

Am Sonntag, 26. Mai 2013, 18:15:46 schrieb Rick "Zero_Chaos" Farina:
> 
> Perhaps this was covered already, but how exactly did this one file,
> added by your co-maintainer, hurt you?  Did it cause additional bugs?
> Did it break a working ebuild?  Did it kill your cat?
> 

+1

-- 

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] Going against co-maintainer's wishes (ref. bug 412697)

[Pacho Ramos]

El dom, 26-05-2013 a las 15:23 +0800, Ben de Groot escribió:
[...]
> But it isn't even like that. I'm not taking away anyone's freedom to
> use systemd. 

You are doing as you are forcing them to have a semi-usable setup when
merging packages.

> You can do so if you wish. You can add unit files to your
> system by yourself, or use an overlay. There are various ways this
> could be realized even within Gentoo.

Who are you to force people to use an overlay? Why are you forbidding
the inclusion of unit files? Maybe you could also have a separate
overlay called "systemd-haters" to maintain that ebuilds done to
obstacle systemd usage.

> 
> But you seem to dismiss all of those, and will only be happy by
> forcing maintainers to add support to packages they maintain, even if
> they believe it is a bad idea.
> 
Nobody is forcing you to maintain that unit file: the unit file will be
maintained by the other co-maintainer or systemd team if he cannot do
that.

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Pacho Ramos]

El dom, 26-05-2013 a las 00:14 +0800, Ben de Groot escribió:
> I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing
> list, since this discussion doesn't really belong on bugzilla.
> 
> Some background copied from the bug report:
[...]

Probably your following comment in bug report summarizes the real
reasons pointing you to not apply that patch after waiting a year for
upstream action:
https://bugs.gentoo.org/show_bug.cgi?id=412697#c8

Reading your comments in bug report gave me the impression of you
refusing to provide the unit file simply to try to interfere as much as
possible with getting higher systemd compatibility in Gentoo, even if I
don't see how adding the unit file will hurt openrc users and how it
will hurt you (as co-maintainer) when another dev is taking care of unit
file and systemd team can also maintain it.

We can now have long discussions about upstream decisions, how to handle
devrel problems... but I think it's much more easy: this kind of
"boycott" attitudes should stop in favor of common sense.

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Carlos Silva]

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

Ben, you're really just being a child here. Is that a really big problem to
add a small text file to your package?! Is that a big maintaining burden?

If you can't test it, systemd team can, just like there are arch teams to
test packages on other archs the maintainers can't. It's not something that
changes code or functionality to that level that it can't be maintained
with help.

Nobody is forcing you to use systemd, there are just people how are asking
to let them use it.

You talk a lot about Gentoo is about choice, but you are not giving that
choice. You're forcing people to *not* use systemd (not using something
else), because you don't like it. Plain simple.


On Sat, May 25, 2013 at 5:00 PM, Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 26-05-2013 a las 00:14 +0800, Ben de Groot escribió:
> > I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing
> > list, since this discussion doesn't really belong on bugzilla.
> >
> > Some background copied from the bug report:
> [...]
>
> Probably your following comment in bug report summarizes the real
> reasons pointing you to not apply that patch after waiting a year for
> upstream action:
> https://bugs.gentoo.org/show_bug.cgi?id=412697#c8
>
> Reading your comments in bug report gave me the impression of you
> refusing to provide the unit file simply to try to interfere as much as
> possible with getting higher systemd compatibility in Gentoo, even if I
> don't see how adding the unit file will hurt openrc users and how it
> will hurt you (as co-maintainer) when another dev is taking care of unit
> file and systemd team can also maintain it.
>
> We can now have long discussions about upstream decisions, how to handle
> devrel problems... but I think it's much more easy: this kind of
> "boycott" attitudes should stop in favor of common sense.
>
>
>

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

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Ben de Groot]

On 26 May 2013 01:00, Pacho Ramos <pacho@gentoo.org> wrote:
> We can now have long discussions about upstream decisions, how to handle
> devrel problems... but I think it's much more easy: this kind of
> "boycott" attitudes should stop in favor of common sense.

Common sense would be to recognize that systemd is a bad
implementation of a bad idea, and to boycott it distro-wide.

But you know what they say about common sense...

--
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Pacho Ramos]

El dom, 26-05-2013 a las 15:15 +0800, Ben de Groot escribió:
> On 26 May 2013 01:00, Pacho Ramos <pacho@gentoo.org> wrote:
> > We can now have long discussions about upstream decisions, how to handle
> > devrel problems... but I think it's much more easy: this kind of
> > "boycott" attitudes should stop in favor of common sense.
> 
> Common sense would be to recognize that systemd is a bad
> implementation of a bad idea, and to boycott it distro-wide.
> 
> But you know what they say about common sense...
> 
> --
> Cheers,
> 
> Ben | yngwin
> Gentoo developer
> 
> 

Call it then: don't hurt others only because you hate systemd. Again,
including that unit file won't hurt you at all

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Michał Górny]

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

On Sun, 26 May 2013 15:15:18 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 26 May 2013 01:00, Pacho Ramos <pacho@gentoo.org> wrote:
> > We can now have long discussions about upstream decisions, how to handle
> > devrel problems... but I think it's much more easy: this kind of
> > "boycott" attitudes should stop in favor of common sense.
> 
> Common sense would be to recognize that systemd is a bad
> implementation of a bad idea, and to boycott it distro-wide.
> 
> But you know what they say about common sense...

As in, say, lastrite GNOME and tell users to switch to other distro?
Or maybe everything using udev? Sounds much like the way to get
the 'one distro' dream some people have. But wasn't the intent opposite?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Luca Barbato]

On 5/26/13 9:45 AM, Michał Górny wrote:
> As in, say, lastrite GNOME and tell users to switch to other distro?
> Or maybe everything using udev? Sounds much like the way to get
> the 'one distro' dream some people have. But wasn't the intent opposite?

eudev was made on purpose to let people avoid systemd if they wanted, 
and it is why people involved on it got stalked and had that much fun.

lu

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 05/25/2013 05:14 PM, Ben de Groot wrote:
> 
> But if a co-maintainer pushes through a change that I oppose, then 
> working together becomes quite difficult. In this case I opted to
> give up maintainership.
> 
Ben,

We've been working together, in the same team(s), for more than 4
years and we never had a single problem in co-maintaining packages. I
would never expected you to make so much noise because I committed a
file (yes a file, *not* a patch) that changes absolutely *nothing* to
existing users but it helps all those users who want to use systemd.

I am very disappointed and confused.

You should have known me better by now.

- -- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQJ8BAEBCgBmBQJRoP9eXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzNTVDNDczOUYzRjJEMTRGNDRGMzU2RkMw
OUJGNEY1NEMyQkE3RjNDAAoJEAm/T1TCun88XWoP/2Jlub+fnEWCx+CJNVZaeP6u
hCISBCdljcihARB+XP2XkTKc4x/VLc9EdMrTIvLOZVheK2qvZ71rul/IxmUOyLmw
m93ui4Dn76UTASqmB6S7RA7qIFGAGs9OBj6oV5xlKVLppGGs/EzsMuguPwI4JmZs
YqGKLHfPZPHmBuTANPq03xICZwnj8vG6vmhiHLamwY0IV7LR4Nx3fN5j4tAxVCfd
m9Q8+ji8ixon72w5utcvQMk0tRAIsOJpWNvu3Aq6SIbOtsrFTHFglADZi5dvJqVk
3Zg51AWz++KvzUL966gk98HnpULtXw7Wh9BpQ0zf1GNfrbfi/MsE2+2ZZ5RfHmKV
5wRgYHAj+3L1sR5xcDVC9nZko5ku8BKuk6PDrpl8fU9j2bGcdbDOniwgGKNxc6+G
LmLKrCJ8OS1QvNAtoIh9ZeQR3Yx1yfkQfFO6+GKuMMFGQ8Ji5spGsUubLa9tSzxz
O6PZGV5zY6ZBen/QDa+dkDmzRdWvK826pxj5w/udDgCR65bzeASAhLEXK/xVVP2H
MhjKv8K9QDFWg1YRVFHTLenKeY2j7rqNJ6+33Rn0MSL/bS9ouNNcK0q1xHZHoHd4
0CMfmBP6vnBHEJxPzJlvhm8XPQwhDiq7BvHlKvHTe6PWJqKr0HuKNH2pwWv8NpYu
0UCknKj9e8QLkdUEtdBK
=QRtO
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Anthony G. Basile]

On 05/25/2013 02:13 PM, Markos Chandras wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 05/25/2013 05:14 PM, Ben de Groot wrote:
>> But if a co-maintainer pushes through a change that I oppose, then
>> working together becomes quite difficult. In this case I opted to
>> give up maintainership.
>>
> Ben,
>
> We've been working together, in the same team(s), for more than 4
> years and we never had a single problem in co-maintaining packages. I
> would never expected you to make so much noise because I committed a
> file (yes a file, *not* a patch) that changes absolutely *nothing* to
> existing users but it helps all those users who want to use systemd.
>
> I am very disappointed and confused.
>
> You should have known me better by now.
>
> - -- 
> Regards,
> Markos Chandras - Gentoo Linux Developer
> http://dev.gentoo.org/~hwoarang
>

We are moving too quickly on bug #448882 ([Tracker] packages not 
providing systemd units).  We should come to better consensus on systemd 
integration and we were getting there with the idea of INSTALL_MASK. I 
don't know that it is a working solution yet.  I have to oppose adding 
unit files unless we have a way to opt out for reasons I gave earlier, 
regarding embedded systems where one needs to conserve space 
aggressively.  And we may have found a way to do so without cluttering 
ebuilds with USE flags.

Can I ask the systemd people to design a working solution for opting 
out?  I can't support this initiative without such a solution and I 
would be happy to work with the systemd people to reach it, ie I'll test.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Mike Gilbert]

On Sat, May 25, 2013 at 3:53 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> Can I ask the systemd people to design a working solution for opting out?  I
> can't support this initiative without such a solution and I would be happy
> to work with the systemd people to reach it, ie I'll test.
>

What about INSTALL_MASK does not work?

I put the responsibility for designing a more idiot-proof opt-out
system in the hands of those that actually care about it. Most of us
are on systems with plenty of storage, and those who are not (embedded
devs) should be perfectly capable of setting INSTALL_MASK without
hosing their systems.

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Anthony G. Basile]

On 05/25/2013 03:58 PM, Mike Gilbert wrote:
> On Sat, May 25, 2013 at 3:53 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> Can I ask the systemd people to design a working solution for opting out?  I
>> can't support this initiative without such a solution and I would be happy
>> to work with the systemd people to reach it, ie I'll test.
>>
> What about INSTALL_MASK does not work?
>
> I put the responsibility for designing a more idiot-proof opt-out
> system in the hands of those that actually care about it. Most of us
> are on systems with plenty of storage, and those who are not (embedded
> devs) should be perfectly capable of setting INSTALL_MASK without
> hosing their systems.
>
Maybe it is sufficient.  I seem to recall someone saying (either on the 
list or IRC) that it needed some work.  If its good enough, then problem 
solved.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Rich Freeman]

On Sat, May 25, 2013 at 3:53 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> We are moving too quickly on bug #448882 ([Tracker] packages not providing
> systemd units).  We should come to better consensus on systemd integration
> and we were getting there with the idea of INSTALL_MASK. I don't know that
> it is a working solution yet.  I have to oppose adding unit files unless we
> have a way to opt out for reasons I gave earlier, regarding embedded systems
> where one needs to conserve space aggressively.  And we may have found a way
> to do so without cluttering ebuilds with USE flags.
>
> Can I ask the systemd people to design a working solution for opting out?  I
> can't support this initiative without such a solution and I would be happy
> to work with the systemd people to reach it, ie I'll test.

This already went before the Council, and the decision was that
INSTALL_MASK IS the working solution for opting out.  If somebody
wants to come up with a better one and propose it they're of course
welcome to, but in the meantime, INSTALL_MASK is the official
solution.

The whole point of having a Council is so that you don't have to reach
100.000000000% consensus on every single decision.

Rich

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Michał Górny]

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

On Sat, 25 May 2013 15:53:21 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> We are moving too quickly on bug #448882 ([Tracker] packages not 
> providing systemd units).  We should come to better consensus on systemd 
> integration and we were getting there with the idea of INSTALL_MASK. I 
> don't know that it is a working solution yet.  I have to oppose adding 
> unit files unless we have a way to opt out for reasons I gave earlier, 
> regarding embedded systems where one needs to conserve space 
> aggressively.  And we may have found a way to do so without cluttering 
> ebuilds with USE flags.

<snarky>

You could drop conf.d and init.d files to save space, unit files are
obviously smaller.

</snarky>

> Can I ask the systemd people to design a working solution for opting 
> out?  I can't support this initiative without such a solution and I 
> would be happy to work with the systemd people to reach it, ie I'll test.

INSTALL_MASK *is* a working solution. And I've designed
app-portage/install-mask which sets it up for you.

If you want something better, just integrate 'keywords' (like
'systemd', 'doc', 'man') into INSTALL_MASK, and be done with it. Just
make sure to store the list of recognized keywords in the repo rather
than keeping it rotting inside portage code.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Tiziano Müller]

Am Samstag, den 25.05.2013, 15:53 -0400 schrieb Anthony G. Basile:
> On 05/25/2013 02:13 PM, Markos Chandras wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 05/25/2013 05:14 PM, Ben de Groot wrote:
> >> But if a co-maintainer pushes through a change that I oppose, then
> >> working together becomes quite difficult. In this case I opted to
> >> give up maintainership.
> >>
> > Ben,
> >
> > We've been working together, in the same team(s), for more than 4
> > years and we never had a single problem in co-maintaining packages. I
> > would never expected you to make so much noise because I committed a
> > file (yes a file, *not* a patch) that changes absolutely *nothing* to
> > existing users but it helps all those users who want to use systemd.
> >
> > I am very disappointed and confused.
> >
> > You should have known me better by now.
> >
> > - -- 
> > Regards,
> > Markos Chandras - Gentoo Linux Developer
> > http://dev.gentoo.org/~hwoarang
> >
> 
> We are moving too quickly on bug #448882 ([Tracker] packages not 
> providing systemd units).  We should come to better consensus on systemd 
> integration and we were getting there with the idea of INSTALL_MASK. I 
> don't know that it is a working solution yet.  I have to oppose adding 
> unit files unless we have a way to opt out for reasons I gave earlier, 
> regarding embedded systems where one needs to conserve space 
> aggressively.  And we may have found a way to do so without cluttering 
> ebuilds with USE flags.

Even though I don't care about a couple of files more on my FS I would
prefer to find a solution with functions provided by PMS, not portage
alone.

> 
> Can I ask the systemd people to design a working solution for opting 
> out?  I can't support this initiative without such a solution and I 
> would be happy to work with the systemd people to reach it, ie I'll test.
> 

Maybe we have to find a more generic solution for this, because there is
bug #235944 [1] which request extra config snippets for rsyslog added to
various packages. Or is this something different? If yes, how?

Best,
Tiziano


[1] https://bugs.gentoo.org/show_bug.cgi?id=235944

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Pacho Ramos]

El dom, 26-05-2013 a las 09:22 +0200, Tiziano Müller escribió:
[...]
> > Can I ask the systemd people to design a working solution for opting 
> > out?  I can't support this initiative without such a solution and I 
> > would be happy to work with the systemd people to reach it, ie I'll test.
> > 
> 
> Maybe we have to find a more generic solution for this, because there is
> bug #235944 [1] which request extra config snippets for rsyslog added to
> various packages. Or is this something different? If yes, how?
> 
> Best,
> Tiziano
> 
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=235944
> 

Probably a better solution should be found but, until then, we should
behave with unit files like we behave for all other similar cases (like
logrotate, even init.d files for openrc, bash-completion files...)

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Michał Górny]

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

On Sun, 26 May 2013 09:22:05 +0200
Tiziano Müller <dev-zero@gentoo.org> wrote:

> Am Samstag, den 25.05.2013, 15:53 -0400 schrieb Anthony G. Basile:
> > We are moving too quickly on bug #448882 ([Tracker] packages not 
> > providing systemd units).  We should come to better consensus on systemd 
> > integration and we were getting there with the idea of INSTALL_MASK. I 
> > don't know that it is a working solution yet.  I have to oppose adding 
> > unit files unless we have a way to opt out for reasons I gave earlier, 
> > regarding embedded systems where one needs to conserve space 
> > aggressively.  And we may have found a way to do so without cluttering 
> > ebuilds with USE flags.
> 
> Even though I don't care about a couple of files more on my FS I would
> prefer to find a solution with functions provided by PMS, not portage
> alone.

PMS doesn't cover configuration, and I feel this is mostly
a configuration problem.

> > Can I ask the systemd people to design a working solution for opting 
> > out?  I can't support this initiative without such a solution and I 
> > would be happy to work with the systemd people to reach it, ie I'll test.
> > 
> 
> Maybe we have to find a more generic solution for this, because there is
> bug #235944 [1] which request extra config snippets for rsyslog added to
> various packages. Or is this something different? If yes, how?

Well, I don't know rsyslog and I have no real idea where those files
end up. But if they end up in a common directory, it's exactly the kind
of thing we can handle with INSTALL_MASK.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)

[Ben de Groot]

On 26 May 2013 02:13, Markos Chandras <hwoarang@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 05/25/2013 05:14 PM, Ben de Groot wrote:
>>
>> But if a co-maintainer pushes through a change that I oppose, then
>> working together becomes quite difficult. In this case I opted to
>> give up maintainership.
>>
> Ben,
>
> We've been working together, in the same team(s), for more than 4
> years and we never had a single problem in co-maintaining packages. I
> would never expected you to make so much noise because I committed a
> file (yes a file, *not* a patch) that changes absolutely *nothing* to
> existing users but it helps all those users who want to use systemd.
>
> I am very disappointed and confused.
>
> You should have known me better by now.

It is exactly because of our good history together that I was so
surprised and disappointed to see you disregarding my opinion in this,
and dismissing it as my problem.

--
Cheers,

Ben | yngwin
Gentoo developer

[gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))

[Michał Górny]

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

On Sun, 26 May 2013 00:14:36 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> Systemd is diametrically opposed to the FreeBSD, customization,
> extreme configurability, and top-notch developer community aspects of
> that. Systemd upstream developers have made it abundantly clear they
> are not interested in working with Gentoo developers to see to the
> needs of source-based distros. They stand for vertical integration
> instead of customization and configurability.
> 
> And you misunderstood: it is systemd that is aggressively opposed to
> Gentoo. But apparently that doesn't bother some of our developers and
> Gentoo is becoming more and more welcoming to it.

By the way, we should really keep the separation between systemd itself
and the unit files. I agree that systemd is not the best thing we could
have. But the unit file format is, er, good enough -- and has
the advantage of eventually taking a lot of work from our shoulders.

Although some of the ideas (esp. wrt targets) are near to crazy
and awfully hard to understand, that's what we have and trying to do
something else is eventually going to make people's lives harder.

We should *really* work on supporting the unit files within OpenRC
(aside to init.d files). That's a way to at least:

a) reuse the work that has been done upstream already (when it was
done),

b) have common service names and startup behavior in all relevant
distros (which is really beneficial to the users).

Considering the design of OpenRC itself, it wouldn't be *that hard*.
Actually, a method similar to one used in oldnet would simply work.
That is, symlinking init.d files to a common 'systemd-wrapper'
executable which would parse the unit files.


On the completely different topic, I agree that systemd design is far
from the best and the way it's maintained is just bad. I was interested
in the past in creating an improved alternative using compatible file
format and libraries, while choosing a better design, improving
portability and keeping stuff less integrated.

But the fact is -- I doubt it will make sense, much like the eudev
project. And it will take much more work, and give much less
appreciation.

First of all, working on it will require a lot of work. Seeing how
large systemd become and how rapidly it is developing, establishing
a good alternative (even dropping such useless parts as the Journal)
will take at least twice that work.

Then, it will require people working on it. People who know the details
of various systems and who are willing to spend their time on it.
And there wouldn't be much of people really willing to work on it.

The systemd haters will refuse the project because of its resemblance
to systemd. The systemd lovers will refuse it because of its
resemblance to systemd. And the OpenRC lovers will want to design it
to resemble OpenRC which is just pointless. Then the few remaining
people will find systemd 'good enough'.

And even if there are a few people who will want to work on it,
and design a 'good systemd', they wouldn't get much appreciation.
Fedora definitely won't care for it. It would have to be really
definitely awesome for most Linux distros to even notice it.
And I doubt *BSD people would be interested in something external.

It is possible that systemd upstream will steal a few patches or ideas
from it. Yet they will never apply any of the really important changes,
so the project will have to be maintained indefinitely. The only hope
for it would be to win over systemd users which I doubt will happen.

So there's a lot of work, no fame or money in it, and most likely more
work being the only future. Anyone volunteering?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))

[Ben de Groot]

On 26 May 2013 15:37, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 26 May 2013 00:14:36 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>
>> Systemd is diametrically opposed to the FreeBSD, customization,
>> extreme configurability, and top-notch developer community aspects of
>> that. Systemd upstream developers have made it abundantly clear they
>> are not interested in working with Gentoo developers to see to the
>> needs of source-based distros. They stand for vertical integration
>> instead of customization and configurability.
>>
>> And you misunderstood: it is systemd that is aggressively opposed to
>> Gentoo. But apparently that doesn't bother some of our developers and
>> Gentoo is becoming more and more welcoming to it.
>
> By the way, we should really keep the separation between systemd itself
> and the unit files. I agree that systemd is not the best thing we could
> have. But the unit file format is, er, good enough -- and has
> the advantage of eventually taking a lot of work from our shoulders.
>
> Although some of the ideas (esp. wrt targets) are near to crazy
> and awfully hard to understand, that's what we have and trying to do
> something else is eventually going to make people's lives harder.
>
> We should *really* work on supporting the unit files within OpenRC
> (aside to init.d files). That's a way to at least:
>
> a) reuse the work that has been done upstream already (when it was
> done),
>
> b) have common service names and startup behavior in all relevant
> distros (which is really beneficial to the users).
>
> Considering the design of OpenRC itself, it wouldn't be *that hard*.
> Actually, a method similar to one used in oldnet would simply work.
> That is, symlinking init.d files to a common 'systemd-wrapper'
> executable which would parse the unit files.

I think this idea actually makes sense. Re-using upstream work seems a
logical idea, and could ease maintenance. Of course the issue is
whether the OpenRC devs see any benefit in this.

> On the completely different topic, I agree that systemd design is far
> from the best and the way it's maintained is just bad. I was interested
> in the past in creating an improved alternative using compatible file
> format and libraries, while choosing a better design, improving
> portability and keeping stuff less integrated.
>
> But the fact is -- I doubt it will make sense, much like the eudev
> project. And it will take much more work, and give much less
> appreciation.
>
> First of all, working on it will require a lot of work. Seeing how
> large systemd become and how rapidly it is developing, establishing
> a good alternative (even dropping such useless parts as the Journal)
> will take at least twice that work.
>
> Then, it will require people working on it. People who know the details
> of various systems and who are willing to spend their time on it.
> And there wouldn't be much of people really willing to work on it.
>
> The systemd haters will refuse the project because of its resemblance
> to systemd. The systemd lovers will refuse it because of its
> resemblance to systemd. And the OpenRC lovers will want to design it
> to resemble OpenRC which is just pointless. Then the few remaining
> people will find systemd 'good enough'.
>
> And even if there are a few people who will want to work on it,
> and design a 'good systemd', they wouldn't get much appreciation.
> Fedora definitely won't care for it. It would have to be really
> definitely awesome for most Linux distros to even notice it.
> And I doubt *BSD people would be interested in something external.
>
> It is possible that systemd upstream will steal a few patches or ideas
> from it. Yet they will never apply any of the really important changes,
> so the project will have to be maintained indefinitely. The only hope
> for it would be to win over systemd users which I doubt will happen.
>
> So there's a lot of work, no fame or money in it, and most likely more
> work being the only future. Anyone volunteering?

I agree it would be pretty hard to carve out a niche for this.
Personally I would see more in runit.

--
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))

[Rich Freeman]

On Sun, May 26, 2013 at 4:32 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 26 May 2013 15:37, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> Considering the design of OpenRC itself, it wouldn't be *that hard*.
>> Actually, a method similar to one used in oldnet would simply work.
>> That is, symlinking init.d files to a common 'systemd-wrapper'
>> executable which would parse the unit files.
>
> I think this idea actually makes sense. Re-using upstream work seems a
> logical idea, and could ease maintenance. Of course the issue is
> whether the OpenRC devs see any benefit in this.

Init.d scripts are just shell scripts.  All somebody needs to do is
write a shell script that parses a unit file and does what it says,
and exports an openrc-oriented init.d environment.  That can be
packaged separately, or whatever, and maybe an eclass could make it
easy to install (point it at the upstream/filesdir unit and tell it
what to call the init.d script, and you get the appropriate
symlink/script).

The OpenRC devs don't have to endorse anything - sure it would make
sense to bundle it, but it could just as easily be pulled in as a dep
or used manually by a user.

The script could ignore any unit features that aren't implemented.
You can ignore settings like auto-restart/inetd and just use the
settings that get the daemon started.

Rich

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))

[Robert David]

On Sun, 26 May 2013 05:49:48 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sun, May 26, 2013 at 4:32 AM, Ben de Groot <yngwin@gentoo.org>
> wrote:
> > On 26 May 2013 15:37, Michał Górny <mgorny@gentoo.org> wrote:
> >>
> >> Considering the design of OpenRC itself, it wouldn't be *that
> >> hard*. Actually, a method similar to one used in oldnet would
> >> simply work. That is, symlinking init.d files to a common
> >> 'systemd-wrapper' executable which would parse the unit files.
> >
> > I think this idea actually makes sense. Re-using upstream work
> > seems a logical idea, and could ease maintenance. Of course the
> > issue is whether the OpenRC devs see any benefit in this.
> 
> Init.d scripts are just shell scripts.  All somebody needs to do is
> write a shell script that parses a unit file and does what it says,
> and exports an openrc-oriented init.d environment.  That can be
> packaged separately, or whatever, and maybe an eclass could make it
> easy to install (point it at the upstream/filesdir unit and tell it
> what to call the init.d script, and you get the appropriate
> symlink/script).
> 
> The OpenRC devs don't have to endorse anything - sure it would make
> sense to bundle it, but it could just as easily be pulled in as a dep
> or used manually by a user.
> 
> The script could ignore any unit features that aren't implemented.
> You can ignore settings like auto-restart/inetd and just use the
> settings that get the daemon started.
> 
> Rich
> 

+1

I would rather add shell script to parse unit and generate appropriate
init script while building than have initscript wrapper that will call
and parse on execution. As you said, some eclass.

Robert.

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))

[Michał Górny]

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

On Sun, 26 May 2013 12:12:49 +0200
Robert David <robert.david.public@gmail.com> wrote:

> On Sun, 26 May 2013 05:49:48 -0400
> Rich Freeman <rich0@gentoo.org> wrote:
> 
> > On Sun, May 26, 2013 at 4:32 AM, Ben de Groot <yngwin@gentoo.org>
> > wrote:
> > > On 26 May 2013 15:37, Michał Górny <mgorny@gentoo.org> wrote:
> > >>
> > >> Considering the design of OpenRC itself, it wouldn't be *that
> > >> hard*. Actually, a method similar to one used in oldnet would
> > >> simply work. That is, symlinking init.d files to a common
> > >> 'systemd-wrapper' executable which would parse the unit files.
> > >
> > > I think this idea actually makes sense. Re-using upstream work
> > > seems a logical idea, and could ease maintenance. Of course the
> > > issue is whether the OpenRC devs see any benefit in this.
> > 
> > Init.d scripts are just shell scripts.  All somebody needs to do is
> > write a shell script that parses a unit file and does what it says,
> > and exports an openrc-oriented init.d environment.  That can be
> > packaged separately, or whatever, and maybe an eclass could make it
> > easy to install (point it at the upstream/filesdir unit and tell it
> > what to call the init.d script, and you get the appropriate
> > symlink/script).
> > 
> > The OpenRC devs don't have to endorse anything - sure it would make
> > sense to bundle it, but it could just as easily be pulled in as a dep
> > or used manually by a user.
> > 
> > The script could ignore any unit features that aren't implemented.
> > You can ignore settings like auto-restart/inetd and just use the
> > settings that get the daemon started.
>
> +1
> 
> I would rather add shell script to parse unit and generate appropriate
> init script while building than have initscript wrapper that will call
> and parse on execution. As you said, some eclass.

This effectively duplicates data for no real benefit.

1) we waste disk space.

2) if user modifies init.d script, systemd unit is out-of-sync.
And the init.d is rewritten (potentially with CONFIG_PROTECT) on next
upgrade.

3) if user modifies systemd unit, init.d script is out-of-sync.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))

[Rich Freeman]

On Sun, May 26, 2013 at 6:31 AM, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 26 May 2013 12:12:49 +0200
> Robert David <robert.david.public@gmail.com> wrote:
>
>> On Sun, 26 May 2013 05:49:48 -0400
>> Rich Freeman <rich0@gentoo.org> wrote:
>>
>> > Init.d scripts are just shell scripts.  All somebody needs to do is
>> > write a shell script that parses a unit file and does what it says,
>> > and exports an openrc-oriented init.d environment.  That can be
>> > packaged separately, or whatever, and maybe an eclass could make it
>> > easy to install (point it at the upstream/filesdir unit and tell it
>> > what to call the init.d script, and you get the appropriate
>> > symlink/script).
>> >
>>
>> I would rather add shell script to parse unit and generate appropriate
>> init script while building than have initscript wrapper that will call
>> and parse on execution. As you said, some eclass.
>
> This effectively duplicates data for no real benefit.
>
> 2) if user modifies init.d script, systemd unit is out-of-sync.
> And the init.d is rewritten (potentially with CONFIG_PROTECT) on next
> upgrade.
>
> 3) if user modifies systemd unit, init.d script is out-of-sync.
>

To clarify, I was agreeing with the use of a wrapper script - likely
symlinked.  It would not be compiled/generated at install time, beyond
creating the symlink and maybe a conf.d file that pointed to the unit.
 The eclass would just streamline the installation.  As you point out
that keeps the configs always in-sync.  It also means that if the
wrapper script is upgraded to add new features all packages benefit,
without needing a re-install.

Rich

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))

[Robert David]

On Sun, 26 May 2013 12:31:25 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 26 May 2013 12:12:49 +0200
> Robert David <robert.david.public@gmail.com> wrote:
> 
> > On Sun, 26 May 2013 05:49:48 -0400
> > Rich Freeman <rich0@gentoo.org> wrote:
> > 
> > > On Sun, May 26, 2013 at 4:32 AM, Ben de Groot <yngwin@gentoo.org>
> > > wrote:
> > > > On 26 May 2013 15:37, Michał Górny <mgorny@gentoo.org> wrote:
> > > >>
> > > >> Considering the design of OpenRC itself, it wouldn't be *that
> > > >> hard*. Actually, a method similar to one used in oldnet would
> > > >> simply work. That is, symlinking init.d files to a common
> > > >> 'systemd-wrapper' executable which would parse the unit files.
> > > >
> > > > I think this idea actually makes sense. Re-using upstream work
> > > > seems a logical idea, and could ease maintenance. Of course the
> > > > issue is whether the OpenRC devs see any benefit in this.
> > > 
> > > Init.d scripts are just shell scripts.  All somebody needs to do
> > > is write a shell script that parses a unit file and does what it
> > > says, and exports an openrc-oriented init.d environment.  That
> > > can be packaged separately, or whatever, and maybe an eclass
> > > could make it easy to install (point it at the upstream/filesdir
> > > unit and tell it what to call the init.d script, and you get the
> > > appropriate symlink/script).
> > > 
> > > The OpenRC devs don't have to endorse anything - sure it would
> > > make sense to bundle it, but it could just as easily be pulled in
> > > as a dep or used manually by a user.
> > > 
> > > The script could ignore any unit features that aren't implemented.
> > > You can ignore settings like auto-restart/inetd and just use the
> > > settings that get the daemon started.
> >
> > +1
> > 
> > I would rather add shell script to parse unit and generate
> > appropriate init script while building than have initscript wrapper
> > that will call and parse on execution. As you said, some eclass.
> 
> This effectively duplicates data for no real benefit.
> 
> 1) we waste disk space.

Come on, it is 2013, wasting few inodes. I did not got these problems
in the old good times with my 386 with 4mb ram and few MB hdd.
Those with embedded system will mask many other files, not only
systemd units (so they save one inode more with my approach, when need
no initscript-wrapper).
Users of regular server/desktops/laptops, 10-20 inodes more? They would
rather won't use Gentoo with its portage tree or do not compile
kernel sources, etc.

> 
> 2) if user modifies init.d script, systemd unit is out-of-sync.
> And the init.d is rewritten (potentially with CONFIG_PROTECT) on next
> upgrade.

If someone update iniscript, must be prepared to be outofsync with
package version. Thus CONFIG_PROTECT.

> 
> 3) if user modifies systemd unit, init.d script is out-of-sync.
>

Why someone will modify systemd unit when will be using init.d
scripts. And for those few people doing this, the same script as portage
use for converting can be used.

Robert.

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd

[Luca Barbato]

On 5/26/13 1:31 PM, Robert David wrote:
> Come on, it is 2013, wasting few inodes. I did not got these problems
> in the old good times with my 386 with 4mb ram and few MB hdd.
> Those with embedded system will mask many other files, not only
> systemd units (so they save one inode more with my approach, when need
> no initscript-wrapper).
> Users of regular server/desktops/laptops, 10-20 inodes more? They would
> rather won't use Gentoo with its portage tree or do not compile
> kernel sources, etc.

The fact we are already the worst offenders won't make thinking about 
impacting a little less not that important.

System with the problem keep portage in a separate fs.

lu

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd

[Luca Barbato]

On 5/26/13 9:37 AM, Michał Górny wrote:
> By the way, we should really keep the separation between systemd itself
> and the unit files. I agree that systemd is not the best thing we could
> have. But the unit file format is, er, good enough -- and has
> the advantage of eventually taking a lot of work from our shoulders.

Unit files had been considered when I started exploring the idea, sadly 
Joost shown me their limitation wouldn't make people life exactly happy.

> Although some of the ideas (esp. wrt targets) are near to crazy
> and awfully hard to understand, that's what we have and trying to do
> something else is eventually going to make people's lives harder.

Making better mousetraps usually works fine: as long you have generators 
that are good enough to get something working nobody would complain.

> We should *really* work on supporting the unit files within OpenRC
> (aside to init.d files). That's a way to at least:
>
> a) reuse the work that has been done upstream already (when it was
> done),
>
> b) have common service names and startup behavior in all relevant
> distros (which is really beneficial to the users).

Can be done notwithstanding the rest.

> Considering the design of OpenRC itself, it wouldn't be *that hard*.

It is sort of simple.

> Actually, a method similar to one used in oldnet would simply work.
> That is, symlinking init.d files to a common 'systemd-wrapper'
> executable which would parse the unit files.

A compiler is an option as well, as said unit -> runscript should map fine.

> On the completely different topic, I agree that systemd design is far
> from the best and the way it's maintained is just bad. I was interested
> in the past in creating an improved alternative using compatible file
> format and libraries, while choosing a better design, improving
> portability and keeping stuff less integrated.
>
> But the fact is -- I doubt it will make sense, much like the eudev
> project. And it will take much more work, and give much less
> appreciation.

Having stand alone component would probably win you many friends and if 
the whole thing could work on something 
non-linux-latest-with-latest-glibc you'd have one less technical concern.

> First of all, working on it will require a lot of work. Seeing how
> large systemd become and how rapidly it is developing, establishing
> a good alternative (even dropping such useless parts as the Journal)
> will take at least twice that work.

You make clean blueprints, get enough people agreeing with them and 
implement simple workalike for what you care about.

For example logind seems to be the current fad.

> The systemd haters will refuse the project because of its resemblance
> to systemd. The systemd lovers will refuse it because of its
> resemblance to systemd. And the OpenRC lovers will want to design it
> to resemble OpenRC which is just pointless. Then the few remaining
> people will find systemd 'good enough'.

systemd haters, as you name them, could be split in few groups:

- those that consider systemd a bad idea because it is a single item 
with many parts that would break horribly, if your idea is to make it 
less tightly coupled and with less parts many would consider helping.

- those that consider systemd a bad idea because of the force feeding 
theme started with udev incorporation and continued with logind and 
such, again if you are creating alternatives the people would help gladly.

- those that consider key part of systemd just wrong the limitation in 
the unit format or path activation as panacea, in that case you have to 
make clear the scope of your project, you might win few or lose some.

> And even if there are a few people who will want to work on it,
> and design a 'good systemd', they wouldn't get much appreciation.
> Fedora definitely won't care for it. It would have to be really
> definitely awesome for most Linux distros to even notice it.
> And I doubt *BSD people would be interested in something external.

Make it bsd and they would consider helping.

> It is possible that systemd upstream will steal a few patches or ideas
> from it. Yet they will never apply any of the really important changes,
> so the project will have to be maintained indefinitely. The only hope
> for it would be to win over systemd users which I doubt will happen.

Or just make something useful, winning or losing is for the people using 
it. If it works and works fine people will use it.

> So there's a lot of work, no fame or money in it, and most likely more
> work being the only future. Anyone volunteering?

Probably would be better sit down, figure out exactly what you want and 
see who has interest:

E.g.

Init-project

- portable   -> must work on non-linux and non-glibc more or less decently
- modular    -> loose coupling of functionality
- robust     -> the core functionality must not crash or remain 
inconsistent because of libdbus or such often occurring problems 
unrelated to
- compatible -> should grok at least a good subset of systemd unit files.


On a side note I really want to know in detail why you loathe openrc 
with this strength but we can discuss on irc.

lu

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd

[Michał Górny]

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

On Sun, 26 May 2013 12:23:51 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 5/26/13 9:37 AM, Michał Górny wrote:
> > By the way, we should really keep the separation between systemd itself
> > and the unit files. I agree that systemd is not the best thing we could
> > have. But the unit file format is, er, good enough -- and has
> > the advantage of eventually taking a lot of work from our shoulders.
> 
> Unit files had been considered when I started exploring the idea, sadly 
> Joost shown me their limitation wouldn't make people life exactly happy.

There are always people who are unhappy with anything you'd change.
Sometimes it's just about changing the way you see things. I can't tell
more without knowing the details though.

> > First of all, working on it will require a lot of work. Seeing how
> > large systemd become and how rapidly it is developing, establishing
> > a good alternative (even dropping such useless parts as the Journal)
> > will take at least twice that work.
> 
> You make clean blueprints, get enough people agreeing with them and 
> implement simple workalike for what you care about.
> 
> For example logind seems to be the current fad.

You're probably right here. But I would have to have the time to work
on it, and as you probably noticed I'm engaged in too many projects
right now.

> > The systemd haters will refuse the project because of its resemblance
> > to systemd. The systemd lovers will refuse it because of its
> > resemblance to systemd. And the OpenRC lovers will want to design it
> > to resemble OpenRC which is just pointless. Then the few remaining
> > people will find systemd 'good enough'.
> 
> systemd haters, as you name them, could be split in few groups:
> 
> - those that consider systemd a bad idea because it is a single item 
> with many parts that would break horribly, if your idea is to make it 
> less tightly coupled and with less parts many would consider helping.
> 
> - those that consider systemd a bad idea because of the force feeding 
> theme started with udev incorporation and continued with logind and 
> such, again if you are creating alternatives the people would help gladly.
> 
> - those that consider key part of systemd just wrong the limitation in 
> the unit format or path activation as panacea, in that case you have to 
> make clear the scope of your project, you might win few or lose some.

You are right again. The outcome would be probably a very modular
project which some parts will be used more frequently and others
infrequently.

But the fact is -- that as far as I see it -- we should be working on
replacing all of systemd components. Mixing tightly-coupled parts of
systemd with external replacements seems wrong.

> > And even if there are a few people who will want to work on it,
> > and design a 'good systemd', they wouldn't get much appreciation.
> > Fedora definitely won't care for it. It would have to be really
> > definitely awesome for most Linux distros to even notice it.
> > And I doubt *BSD people would be interested in something external.
> 
> Make it bsd and they would consider helping.

I'm not really sure about this. For some of the components probably
yes. But the general init replacement / unit runner is not something
I'd expect much help with.

> > So there's a lot of work, no fame or money in it, and most likely more
> > work being the only future. Anyone volunteering?
> 
> Probably would be better sit down, figure out exactly what you want and 
> see who has interest:
> 
> E.g.
> 
> Init-project
> 
> - portable   -> must work on non-linux and non-glibc more or less decently
> - modular    -> loose coupling of functionality
> - robust     -> the core functionality must not crash or remain 
> inconsistent because of libdbus or such often occurring problems 
> unrelated to
> - compatible -> should grok at least a good subset of systemd unit files.

Quite a good summary, I'd say.

> On a side note I really want to know in detail why you loathe openrc 
> with this strength but we can discuss on irc.

I'd suspect this is mostly with the growing irritation of systemd
haters who spawn endless threads about how they hate anything with
'systemd' name in it. Plus the people who try hard to port the mistakes
of OpenRC init scripts to systemd services files.

I have my limits, and I'd really prefer doing something useful rather
than setting up random things straight, fighting developers and making
sure everything keeps working in a semi-sane way.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd

[Luca Barbato]

On 5/26/13 1:15 PM, Michał Górny wrote:
> I'd suspect this is mostly with the growing irritation of systemd
> haters who spawn endless threads about how they hate anything with
> 'systemd' name in it. Plus the people who try hard to port the mistakes
> of OpenRC init scripts to systemd services files.

Here we have a problem, the people that need more flexibility to 
actually get work done will see that the inflexibility of the unit 
format will bite them and bite them hard.

A simple example is something fairly easy for a runscript and quite 
annoying for an unit, multiple instances.

for openrc you can just symlink using a proper pattern and have the 
initscript figure the right configuration and which user/chroot use to 
drop the daemon.

for systemd you have to copy and edit since most fields are immutable 
(some are with special rules).

This is something you tend to use a lot for certain kind of services and 
is made really easy and uniform in openrc while lsb and freebsd tend to 
have per-script rules.

> I have my limits, and I'd really prefer doing something useful rather
> than setting up random things straight, fighting developers and making
> sure everything keeps working in a semi-sane way.

Your dedication is commendable, I do appreciate your help in Gentoo a 
lot even if we can disagree on some decisions.

I know that discussing systemd can get quite annoying since it can 
easily drift from technical (e.g. my concern regarding dbus) political 
(systemd as Trojan horse for something else and other strategical 
concerns), or personal (some people consider Lennart a 
dangerous/poisonous person) and gets quite easy to mix things up and end 
up discounting technical concerns by telling that you said this or that 
just because you hate Lennart.

lu

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd

[Sergei Trofimovich]

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

On Sun, 26 May 2013 13:59:34 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 5/26/13 1:15 PM, Michał Górny wrote:
> > I'd suspect this is mostly with the growing irritation of systemd
> > haters who spawn endless threads about how they hate anything with
> > 'systemd' name in it. Plus the people who try hard to port the mistakes
> > of OpenRC init scripts to systemd services files.
> 
> Here we have a problem, the people that need more flexibility to 
> actually get work done will see that the inflexibility of the unit 
> format will bite them and bite them hard.
> 
> A simple example is something fairly easy for a runscript and quite 
> annoying for an unit, multiple instances.
> 
> for openrc you can just symlink using a proper pattern and have the 
> initscript figure the right configuration and which user/chroot use to 
> drop the daemon.

You need to name a unit with @ suffix, like openvpn@.service:

    $ cat /etc/systemd/system/openvpn@.service 
    [Service]
    Type=simple
    ExecStart=/usr/sbin/openvpn --user openvpn --group openvpn --cd /etc/openvpn --chroot /var/run/openvpn --config %I.conf

feel free to sprinkle %i (and others) for templating.

and symlink it as you like. openvpn@foo.service (or openvpn@foo)
will be direct analogue to openvpn.foo. (+ foo.service.d with the same(?) override semantics)

> for systemd you have to copy and edit since most fields are immutable 
> (some are with special rules).

    .include /path/to/unit
    OverrideedField = OverridedValue
will not help here, right?

-- 

  Sergei

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

Re: [gentoo-dev] Reusing systemd unit file format / forking systemd

[Luca Barbato]

On 5/26/13 3:35 PM, Sergei Trofimovich wrote:
> On Sun, 26 May 2013 13:59:34 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> You need to name a unit with @ suffix, like openvpn@.service:
>
>      $ cat /etc/systemd/system/openvpn@.service
>      [Service]
>      Type=simple
>      ExecStart=/usr/sbin/openvpn --user openvpn --group openvpn --cd /etc/openvpn --chroot /var/run/openvpn --config %I.conf
>
> feel free to sprinkle %i (and others) for templating.

Feel free to check which fields accept %expansions and which do not, 
last time I heard some fields do not. If it had been fixed I'm glad.

lu