Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Austin English-2
Hi there,

I've been working on the transition from #!/sbin/runscript to
#!/sbin/openrc-run [1], by starting on the maintainer-needed packages.
That's done (aside from some stabilizations needed, but I'll deal with that
latter). The trouble is that there are roughly 700 packages that need to
be updated, and that's an insane number of bugs to file.

So, instead, I'm going to give developers to two weeks to update their
initscripts or ask me not to touch it. On/after 2016/05/18, I'll update
initscripts/copyrights, but will leave revbumping to maintainer's discretion.

Thanks,
Austin

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



signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Patrick Lauer
On 05/04/2016 06:27 AM, Austin English wrote:
> Hi there,
>
> I've been working on the transition from #!/sbin/runscript to
> #!/sbin/openrc-run [1],
... and once more I have to ask:

Is there any reason that Stuff Needs To Change because of a packaging
conflict in *debian* where it really doesn't matter at all for us?

I mean, ok, it's your time, do what you want, but I'm still confused
about the benefits of this change ...

>  by starting on the maintainer-needed packages.
> That's done (aside from some stabilizations needed, but I'll deal with that
> latter). The trouble is that there are roughly 700 packages that need to
> be updated, and that's an insane number of bugs to file.
>
> So, instead, I'm going to give developers to two weeks to update their
> initscripts or ask me not to touch it. On/after 2016/05/18, I'll update
> initscripts/copyrights, but will leave revbumping to maintainer's discretion.
>
> Thanks,
> Austin
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=573846
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Austin English-2
On 05/04/2016 01:02 AM, Patrick Lauer wrote:

> On 05/04/2016 06:27 AM, Austin English wrote:
>> Hi there,
>>
>> I've been working on the transition from #!/sbin/runscript to
>> #!/sbin/openrc-run [1],
> ... and once more I have to ask:
>
> Is there any reason that Stuff Needs To Change because of a packaging
> conflict in *debian* where it really doesn't matter at all for us?
>
> I mean, ok, it's your time, do what you want, but I'm still confused
> about the benefits of this change ...
OpenRC isn't exclusive to Gentoo. Why should we use the generic #!bin/sh
when we usually intend #!/bin/bash? Because being explicit is nice
instead of relying on implementation details.

Additionally, you know, it helps the wider open source community. Most
would call that a beneficial thing. You're welcome to your own opinion.

Regardless, if you have a a technical objection rather than an objection
to following upstream's recommendations, I'm listening.

>>  by starting on the maintainer-needed packages.
>> That's done (aside from some stabilizations needed, but I'll deal with that
>> latter). The trouble is that there are roughly 700 packages that need to
>> be updated, and that's an insane number of bugs to file.
>>
>> So, instead, I'm going to give developers to two weeks to update their
>> initscripts or ask me not to touch it. On/after 2016/05/18, I'll update
>> initscripts/copyrights, but will leave revbumping to maintainer's discretion.
>>
>> Thanks,
>> Austin
>>
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=573846
>>
>>
>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Ulrich Mueller-2
In reply to this post by Austin English-2
>>>>> On Tue, 3 May 2016, Austin English wrote:

> I've been working on the transition from #!/sbin/runscript to
> #!/sbin/openrc-run [1], by starting on the maintainer-needed
> packages. That's done (aside from some stabilizations needed, but
> I'll deal with that latter). The trouble is that there are roughly
> 700 packages that need to be updated, and that's an insane number of
> bugs to file.

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

Your list of affected packages obtained with "git grep" in the Portage
tree will not be complete, since the command won't catch any init
scripts installed from elsewhere. You should look for the set of
installed files instead.

Also, what problem are you trying to solve? My guess would be that
/sbin/runscript must be kept around indefinitely in any case, in order
not to risk breakage on users' systems.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Austin English-2
On 05/04/2016 02:04 AM, Ulrich Mueller wrote:

>>>>>> On Tue, 3 May 2016, Austin English wrote:
>> I've been working on the transition from #!/sbin/runscript to
>> #!/sbin/openrc-run [1], by starting on the maintainer-needed
>> packages. That's done (aside from some stabilizations needed, but
>> I'll deal with that latter). The trouble is that there are roughly
>> 700 packages that need to be updated, and that's an insane number of
>> bugs to file.
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=573846
> Your list of affected packages obtained with "git grep" in the Portage
> tree will not be complete, since the command won't catch any init
> scripts installed from elsewhere. You should look for the set of
> installed files instead.
How is that relevant here at all? I'm cleaning up portage installed init
scripts, what a user does outside of that is a separate problem (for the
init program, not gentoo.git).
 
> Also, what problem are you trying to solve? My guess would be that
> /sbin/runscript must be kept around indefinitely in any case, in order
> not to risk breakage on users' systems.
>
> Ulrich
Again, not my issue. I'm trying to prevent the problem from spreading
further. If only new scripts get openrc-run, the runscript shebang
should be rare in a year now, for example. But again, that's for OpenRC
to decide. That's not reason not to get away from the deprecated name now.


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Ulrich Mueller-2
>>>>> On Wed, 4 May 2016, Austin English wrote:

>> Your list of affected packages obtained with "git grep" in the
>> Portage tree will not be complete, since the command won't catch
>> any init scripts installed from elsewhere. You should look for the
>> set of installed files instead.

> How is that relevant here at all? I'm cleaning up portage installed
> init scripts, [...]

You are cleaning up only those init scripts that are installed from
FILESDIR, but you will miss the ones that are installed from a file
in SRC_URI.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Sam Jorna (wraeth)
On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:

> >>>>> On Wed, 4 May 2016, Austin English wrote:
>
> >> Your list of affected packages obtained with "git grep" in the
> >> Portage tree will not be complete, since the command won't catch
> >> any init scripts installed from elsewhere. You should look for the
> >> set of installed files instead.
>
> > How is that relevant here at all? I'm cleaning up portage installed
> > init scripts, [...]
>
> You are cleaning up only those init scripts that are installed from
> FILESDIR, but you will miss the ones that are installed from a file
> in SRC_URI.
Perhaps an alternate way to do it would be to have a QA check look at
any files installed to ${D}etc/init.d/ and throw a warning if their
shebang is "#!/sbin/runscript"

--
Sam Jorna (wraeth)
GnuPG Key: D6180C26

signature.asc (970 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Kristian Fiskerstrand-2
On 05/04/2016 10:52 AM, Sam Jorna wrote:

> On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:
>>>>>>> On Wed, 4 May 2016, Austin English wrote:
>>
>>>> Your list of affected packages obtained with "git grep" in the
>>>> Portage tree will not be complete, since the command won't catch
>>>> any init scripts installed from elsewhere. You should look for the
>>>> set of installed files instead.
>>
>>> How is that relevant here at all? I'm cleaning up portage installed
>>> init scripts, [...]
>>
>> You are cleaning up only those init scripts that are installed from
>> FILESDIR, but you will miss the ones that are installed from a file
>> in SRC_URI.
>
> Perhaps an alternate way to do it would be to have a QA check look at
> any files installed to ${D}etc/init.d/ and throw a warning if their
> shebang is "#!/sbin/runscript"
>
A repoman check is a much saner approach, I'm not convinced there is
sufficient need for this change to begin with, in particular to start
touching a wide range of packages. Breaking backwards compatibility in
any way should have a darn good reason, and I haven't seen one yet


--
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Duncan-42
In reply to this post by Ulrich Mueller-2
Ulrich Mueller posted on Wed, 04 May 2016 10:00:05 +0200 as excerpted:

>>>>>> On Wed, 4 May 2016, Austin English wrote:
>
>>> Your list of affected packages obtained with "git grep" in the Portage
>>> tree will not be complete, since the command won't catch any init
>>> scripts installed from elsewhere. You should look for the set of
>>> installed files instead.
>
>> How is that relevant here at all? I'm cleaning up portage installed
>> init scripts, [...]
>
> You are cleaning up only those init scripts that are installed from
> FILESDIR, but you will miss the ones that are installed from a file in
> SRC_URI.

While you are correct, the current problem isn't lack of low hanging
fruit to fix in the files dir, as he said there's 700 packages on the
list already, too many to file individual bugs for.

So while it is indeed worthwhile to keep in mind the init-scripts
installed from SRC_URI...

There's seven hundred "miles of open road" to cross before we have to
worry about that SRC_URI bridge, so maybe worry about that when we're
within 50 or 100, or even a couple hundred, "miles", not 700. =:^]

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


Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Sam Jorna (wraeth)
In reply to this post by Kristian Fiskerstrand-2
On Wed, May 04, 2016 at 10:57:44AM +0200, Kristian Fiskerstrand wrote:

> On 05/04/2016 10:52 AM, Sam Jorna wrote:
> > On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:
> >>>>>>> On Wed, 4 May 2016, Austin English wrote:
> >>
> >>>> Your list of affected packages obtained with "git grep" in the
> >>>> Portage tree will not be complete, since the command won't catch
> >>>> any init scripts installed from elsewhere. You should look for the
> >>>> set of installed files instead.
> >>
> >>> How is that relevant here at all? I'm cleaning up portage installed
> >>> init scripts, [...]
> >>
> >> You are cleaning up only those init scripts that are installed from
> >> FILESDIR, but you will miss the ones that are installed from a file
> >> in SRC_URI.
> >
> > Perhaps an alternate way to do it would be to have a QA check look at
> > any files installed to ${D}etc/init.d/ and throw a warning if their
> > shebang is "#!/sbin/runscript"
> >
>
> A repoman check is a much saner approach, I'm not convinced there is
> sufficient need for this change to begin with, in particular to start
> touching a wide range of packages. Breaking backwards compatibility in
> any way should have a darn good reason, and I haven't seen one yet
I'm not arguing for or against it in general, just in terms of technical
implementation.

That being said, a repoman check would only catch those distributed in
${FILESDIR} as well. My thinking with the above was to also identify
those installed from distfiles to be handled accordingly.

--
Sam Jorna (wraeth)
GnuPG Key: D6180C26

signature.asc (970 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Manuel Rüger
In reply to this post by Duncan-42
On 04.05.2016 11:19, Duncan wrote:

> Ulrich Mueller posted on Wed, 04 May 2016 10:00:05 +0200 as excerpted:
>
>>>>>>> On Wed, 4 May 2016, Austin English wrote:
>>
>>>> Your list of affected packages obtained with "git grep" in the Portage
>>>> tree will not be complete, since the command won't catch any init
>>>> scripts installed from elsewhere. You should look for the set of
>>>> installed files instead.
>>
>>> How is that relevant here at all? I'm cleaning up portage installed
>>> init scripts, [...]
>>
>> You are cleaning up only those init scripts that are installed from
>> FILESDIR, but you will miss the ones that are installed from a file in
>> SRC_URI.
>
> While you are correct, the current problem isn't lack of low hanging
> fruit to fix in the files dir, as he said there's 700 packages on the
> list already, too many to file individual bugs for.
>
> So while it is indeed worthwhile to keep in mind the init-scripts
> installed from SRC_URI...
>
> There's seven hundred "miles of open road" to cross before we have to
> worry about that SRC_URI bridge, so maybe worry about that when we're
> within 50 or 100, or even a couple hundred, "miles", not 700. =:^]
>
Hi Austin,

to be honest, I'm not too happy with the fixes you applied.
Although it's just a tiny change, I'd rather have expected a revision
bump to the ebuilds and a revision bump to the init files themselves
than just a in-file rewrite.
Your fix changes the content of files that are installed to ones system.
Such a change usually requires a revbump.


Cheers,

Manuel



signature.asc (618 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Manuel Rüger
On 04.05.2016 14:54, Manuel Rüger wrote:

> On 04.05.2016 11:19, Duncan wrote:
>> Ulrich Mueller posted on Wed, 04 May 2016 10:00:05 +0200 as excerpted:
>>
>>>>>>>> On Wed, 4 May 2016, Austin English wrote:
>>>
>>>>> Your list of affected packages obtained with "git grep" in the Portage
>>>>> tree will not be complete, since the command won't catch any init
>>>>> scripts installed from elsewhere. You should look for the set of
>>>>> installed files instead.
>>>
>>>> How is that relevant here at all? I'm cleaning up portage installed
>>>> init scripts, [...]
>>>
>>> You are cleaning up only those init scripts that are installed from
>>> FILESDIR, but you will miss the ones that are installed from a file in
>>> SRC_URI.
>>
>> While you are correct, the current problem isn't lack of low hanging
>> fruit to fix in the files dir, as he said there's 700 packages on the
>> list already, too many to file individual bugs for.
>>
>> So while it is indeed worthwhile to keep in mind the init-scripts
>> installed from SRC_URI...
>>
>> There's seven hundred "miles of open road" to cross before we have to
>> worry about that SRC_URI bridge, so maybe worry about that when we're
>> within 50 or 100, or even a couple hundred, "miles", not 700. =:^]
>>
>
> Hi Austin,
>
> to be honest, I'm not too happy with the fixes you applied.
> Although it's just a tiny change, I'd rather have expected a revision
> bump to the ebuilds and a revision bump to the init files themselves
> than just a in-file rewrite.
> Your fix changes the content of files that are installed to ones system.
> Such a change usually requires a revbump.
>
>
> Cheers,
>
> Manuel
>
>
Nevermind, I didn't see the follow-up commit in which you removed the
old revision.

Cheers,

Manuel


signature.asc (618 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

William Hubbs
In reply to this post by Sam Jorna (wraeth)
On Wed, May 04, 2016 at 07:41:39PM +1000, Sam Jorna wrote:

> On Wed, May 04, 2016 at 10:57:44AM +0200, Kristian Fiskerstrand wrote:
> > On 05/04/2016 10:52 AM, Sam Jorna wrote:
> > > On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:
> > >>>>>>> On Wed, 4 May 2016, Austin English wrote:
> > >>
> > >>>> Your list of affected packages obtained with "git grep" in the
> > >>>> Portage tree will not be complete, since the command won't catch
> > >>>> any init scripts installed from elsewhere. You should look for the
> > >>>> set of installed files instead.
> > >>
> > >>> How is that relevant here at all? I'm cleaning up portage installed
> > >>> init scripts, [...]
> > >>
> > >> You are cleaning up only those init scripts that are installed from
> > >> FILESDIR, but you will miss the ones that are installed from a file
> > >> in SRC_URI.
> > >
> > > Perhaps an alternate way to do it would be to have a QA check look at
> > > any files installed to ${D}etc/init.d/ and throw a warning if their
> > > shebang is "#!/sbin/runscript"
> > >
> >
> > A repoman check is a much saner approach, I'm not convinced there is
> > sufficient need for this change to begin with, in particular to start
> > touching a wide range of packages. Breaking backwards compatibility in
> > any way should have a darn good reason, and I haven't seen one yet
>
> I'm not arguing for or against it in general, just in terms of technical
> implementation.
>
> That being said, a repoman check would only catch those distributed in
> ${FILESDIR} as well. My thinking with the above was to also identify
> those installed from distfiles to be handled accordingly.
Actually, you won't need to worry about any qa checks in portage,
because I am going to put a deprecation warning in OpenRC upstream which
will be displayed when a service script invokes runscript instructing
you to convert to openrc-run.

OpenRC will keep runscript, with this warning, for a while.

William


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Patrick Lauer
On 05/05/2016 01:12 AM, William Hubbs wrote:

> On Wed, May 04, 2016 at 07:41:39PM +1000, Sam Jorna wrote:
>> On Wed, May 04, 2016 at 10:57:44AM +0200, Kristian Fiskerstrand wrote:
>>> On 05/04/2016 10:52 AM, Sam Jorna wrote:
>>>> On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote:
>>>>>>>>>> On Wed, 4 May 2016, Austin English wrote:
>>>>>>> Your list of affected packages obtained with "git grep" in the
>>>>>>> Portage tree will not be complete, since the command won't catch
>>>>>>> any init scripts installed from elsewhere. You should look for the
>>>>>>> set of installed files instead.
>>>>>> How is that relevant here at all? I'm cleaning up portage installed
>>>>>> init scripts, [...]
>>>>> You are cleaning up only those init scripts that are installed from
>>>>> FILESDIR, but you will miss the ones that are installed from a file
>>>>> in SRC_URI.
>>>> Perhaps an alternate way to do it would be to have a QA check look at
>>>> any files installed to ${D}etc/init.d/ and throw a warning if their
>>>> shebang is "#!/sbin/runscript"
>>>>
>>> A repoman check is a much saner approach, I'm not convinced there is
>>> sufficient need for this change to begin with, in particular to start
>>> touching a wide range of packages. Breaking backwards compatibility in
>>> any way should have a darn good reason, and I haven't seen one yet
>> I'm not arguing for or against it in general, just in terms of technical
>> implementation.
>>
>> That being said, a repoman check would only catch those distributed in
>> ${FILESDIR} as well. My thinking with the above was to also identify
>> those installed from distfiles to be handled accordingly.
> Actually, you won't need to worry about any qa checks in portage,
> because I am going to put a deprecation warning in OpenRC upstream which
> will be displayed when a service script invokes runscript instructing
> you to convert to openrc-run.
>
> OpenRC will keep runscript, with this warning, for a while.
>
>
So again, because I feel like either I'm too stupid to understand this,
or too smart to let such an obviously bad idea continue:

What problem is being solved here?



Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Duncan-42
Patrick Lauer posted on Thu, 05 May 2016 07:13:00 +0200 as excerpted:

> So again, because I feel like either I'm too stupid to understand this,
> or too smart to let such an obviously bad idea continue:
>
> What problem is being solved here?

For one thing, the namespace issue of runscript being generic, while
openrc-run is properly namespaced and thus much less likely to conflict
with anything else.

That would be why openrc's upstream maintainer is changing the name, with
appropriate deprecation notice for the old one.  Given that, what gentoo
has to decide is how it's going to respond to that.  Sure, we /could/
rename the executable to runscript here and be done with it, but that
would violate gentoo's policy of defaulting to consistency with upstream
unless there's a very good reason not to.

The fact that the packages upstream maintainer happens to be a gentoo dev
and that gentoo happens to host the project and be its primary testing
ground and user base shouldn't change that.

Of course if upstream policy is thought by devs willing to do the work to
be irrational, they can of course fork the package.  There's certainly
precedent for that.  But someone's gotta be willing to do the work
necessary to create and maintain that fork, so...

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


Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

M. J. Everitt
On 05/05/16 08:17, Duncan wrote:

> Patrick Lauer posted on Thu, 05 May 2016 07:13:00 +0200 as excerpted:
>
>> So again, because I feel like either I'm too stupid to understand this,
>> or too smart to let such an obviously bad idea continue:
>>
>> What problem is being solved here?
> For one thing, the namespace issue of runscript being generic, while
> openrc-run is properly namespaced and thus much less likely to conflict
> with anything else.
>
> That would be why openrc's upstream maintainer is changing the name, with
> appropriate deprecation notice for the old one.  Given that, what gentoo
> has to decide is how it's going to respond to that.  Sure, we /could/
> rename the executable to runscript here and be done with it, but that
> would violate gentoo's policy of defaulting to consistency with upstream
> unless there's a very good reason not to.
>
> The fact that the packages upstream maintainer happens to be a gentoo dev
> and that gentoo happens to host the project and be its primary testing
> ground and user base shouldn't change that.
>
> Of course if upstream policy is thought by devs willing to do the work to
> be irrational, they can of course fork the package.  There's certainly
> precedent for that.  But someone's gotta be willing to do the work
> necessary to create and maintain that fork, so...
>
+1


signature.asc (919 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Patrick Lauer
In reply to this post by Duncan-42
On 05/05/2016 09:17 AM, Duncan wrote:
> Patrick Lauer posted on Thu, 05 May 2016 07:13:00 +0200 as excerpted:
>
>> So again, because I feel like either I'm too stupid to understand this,
>> or too smart to let such an obviously bad idea continue:
>>
>> What problem is being solved here?
> For one thing, the namespace issue of runscript being generic, while
> openrc-run is properly namespaced and thus much less likely to conflict
> with anything else.
... which wasn't a problem for the first decade. The first time a name
collision was noticed was when debian packaging was attempted.

>
> That would be why openrc's upstream maintainer is changing the name, with
> appropriate deprecation notice for the old one.  Given that, what gentoo
> has to decide is how it's going to respond to that.  Sure, we /could/
> rename the executable to runscript here and be done with it, but that
> would violate gentoo's policy of defaulting to consistency with upstream
> unless there's a very good reason not to.
>
> The fact that the packages upstream maintainer happens to be a gentoo dev
> and that gentoo happens to host the project and be its primary testing
> ground and user base shouldn't change that.
>
> Of course if upstream policy is thought by devs willing to do the work to
> be irrational, they can of course fork the package.  There's certainly
> precedent for that.  But someone's gotta be willing to do the work
> necessary to create and maintain that fork, so...
>
So you're saying that a Gentoo-specific change in Gentoo happens because
the Gentoo maintainer doesn't care about Gentoo? ;)

Somehow I still don't see a *problem* being solved, and the runscript
binary/symlink pretty much has to stay there indefinitely unless you
want to make life exciting for people that have their own or adapted
init scripts.

To summarize: Lots of churn, no visible benefit, except that some OCD
people could feel better: except that we can't actually fix the core
'issue' without making lots of other people very sad.


Y'all have too much free time ... ;)

Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

M. J. Everitt
On 05/05/16 08:32, Patrick Lauer wrote:
> To summarize: Lots of churn, no visible benefit, except that some OCD
> people could feel better: except that we can't actually fix the core
> 'issue' without making lots of other people very sad.
>
>
> Y'all have too much free time ... ;)
>
I'm inclined to say, that provided there *is* someone doing it .. let
them be. Whatever the motives.

We have enough problems with painting the bike shed not to stifle
activity and contribution ...

Just my 2c ... ;]

MJE

Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

Patrick Lauer
On 05/05/2016 09:44 AM, M. J. Everitt wrote:

> On 05/05/16 08:32, Patrick Lauer wrote:
>> To summarize: Lots of churn, no visible benefit, except that some OCD
>> people could feel better: except that we can't actually fix the core
>> 'issue' without making lots of other people very sad.
>>
>>
>> Y'all have too much free time ... ;)
>>
> I'm inclined to say, that provided there *is* someone doing it .. let
> them be. Whatever the motives.
This ignores the externalized cost for potentially thousands of users
that have to fix stuff because it was actively broken.


How much is your time worth?
>
> We have enough problems with painting the bike shed not to stifle
> activity and contribution ...

I dislike repeating myself, but ... "Change is not Progress"
>
> Just my 2c ... ;]
>
> MJE
>


Reply | Threaded
Open this post in threaded view
|

Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

M. J. Everitt
On 05/05/16 08:53, Patrick Lauer wrote:
>
> This ignores the externalized cost for potentially thousands of users
> that have to fix stuff because it was actively broken.
>
To quote an old proverb .. "you can't make an omelette without breaking
eggs" .. if you wish me to explain, I'll do it privately ;)


I don't think anyone (gentoo-wide) is out to make users life difficult,
or make significant work for the precious few package maintainers there
are. There will always be a certain amount of 'change for change's sake'
and whilst there may not always be a direct benefit, there are often
desirable side-effects. I'm not saying this is necessarily a case in
point, though.

I hear the arguments that we are upholding upstream's progression, and I
think that remains one of Gentoo's overriding goals. Sure if its really
a problem for you, fork openrc, maintain it or leave it to bit-rot if
you really think that 'runscript' is the only way to start services.
We/I can't get inside the maintainers head (and wouldn't wish to .. mine
is spaghetti enough already, tyvm!) but rest assured I don't think this
is a debian/fedora/systemd/<insert-your-personal-distaste-here> issue,
and I think we should just let them get on with it, and be grateful we
have been warned, and this isn't an epic surprise that will generate a
whole stack of reverts down-the-line where someone hasn't done a
reasonable impact assessment of their change...

ok, that's $2 now .. I'll shut up .. I got Real Work to do too ...


signature.asc (919 bytes) Download Attachment
12