Bill Nottingham (nott...@redhat.com) said:
> WHEN THIS WILL LAND
>
> It's in initscripts git now, will package shortly for F18/F17/F16.
initscripts-9.38-1.fc18
initscripts-9.37.1-1.fc17
initscripts-9.34.3-1.fc16
to be precise.
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://a
Jonathan Underwood (jonathan.underw...@gmail.com) said:
> On 26 June 2012 21:11, Bill Nottingham wrote:
> > For each legacy option (such as "xyzzy") supported by your init script (such
> > as "frobozz"), package an executable script named:
> >
> > /usr/libexec/initscripts/legacy-actions/frobozz/
On 26 June 2012 21:11, Bill Nottingham wrote:
> For each legacy option (such as "xyzzy") supported by your init script (such
> as "frobozz"), package an executable script named:
>
> /usr/libexec/initscripts/legacy-actions/frobozz/xyzzy
>
Wouldn't
/usr/lib/initscripts/legacy-actions/frobozz/xyzz
"Jóhann B. Guðmundsson" (johan...@gmail.com) said:
> On 06/26/2012 08:11 PM, Bill Nottingham wrote:
> >Questions? Comments?
>
> You do realize what you have effectively just done by this dont you?
Merged a patch from a systemd maintainer?
Bill, not really interested in playing this game
--
de
Miloslav Trmač (m...@volny.cz) said:
> On Tue, Jun 26, 2012 at 10:45 PM, Till Maas wrote:
> >> 2) Don't package a legacy action for new scripts or actions that were not
> >> supported by the prior init script; this is intended for compatibility with
> >> existing scripts and/or administrator brai
Tom Lane (t...@redhat.com) said:
> Bill Nottingham writes:
> > Better late than never (and thanks to Michal Schmidt), I've added support to
> > /sbin/service for running legacy actions if specified.
>
> I'm confused. Only 2 months ago I was told that this was firmly
> against policy and I shoul
On Tue, 2012-06-26 at 21:48 +, "Jóhann B. Guðmundsson" wrote:
> On 06/26/2012 08:49 PM, Miloslav Trmač wrote:
> > The preferred new way is that upstream implements the action in a way
> > that is same across all distributions. Which, in some sense, does not
> > answer your question.
>
> Firs
Mathieu Bridon writes:
> Especially since it handles multiple postgresql instances with an
> optional parameter.
> Tom, can you try to make sure the script
> in /usr/libexec/initscripts/legacy-actions allows the same?
Unless Bill hacked /sbin/service to pass additional parameters through
to the
Michael Cronenworth writes:
> On 06/26/2012 06:54 PM, Tom Lane wrote:
>> I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll
>> be implementing this for postgresql tomorrow, because I'm tired of
>> hearing complaints about it.
> I must be the only one that prefers your separate p
On Tue, 2012-06-26 at 21:51 -0500, Michael Cronenworth wrote:
> On 06/26/2012 06:54 PM, Tom Lane wrote:
> > I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll
> > be implementing this for postgresql tomorrow, because I'm tired of
> > hearing complaints about it.
>
> I must be the
On 06/26/2012 06:54 PM, Tom Lane wrote:
I beg to differ. If Bill doesn't get his wrist slapped by FPC, I'll
be implementing this for postgresql tomorrow, because I'm tired of
hearing complaints about it.
I must be the only one that prefers your separate postgresql-setup
script over the call t
On 06/26/2012 11:54 PM, Tom Lane wrote:
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= writes:
On 06/26/2012 10:12 PM, Miloslav Trma� wrote:
Breaking "service foo action" reason was just an unnecessary
regression that shouldn't have happened in the first place.
Agreed and honestly this sud
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= writes:
> On 06/26/2012 10:12 PM, Miloslav TrmaÄ wrote:
>> Breaking "service foo action" reason was just an unnecessary
>> regression that shouldn't have happened in the first place.
> Agreed and honestly this sudden turnaround now smells a bit li
On 06/26/2012 10:12 PM, Miloslav Trmač wrote:
What is "this"?
Sorry meant to say "this is"
There are maybe a handful of services that need this hence the
precaution clause so packagers/maintainers simply don't choose to do
exactly what Bill was referring to in "3)"
Breaking "service foo
On Tue, Jun 26, 2012 at 05:50:57PM -0400, Tom Lane wrote:
> Bill Nottingham writes:
> > Better late than never (and thanks to Michal Schmidt), I've added support to
> > /sbin/service for running legacy actions if specified.
>
> I'm confused. Only 2 months ago I was told that this was firmly
> ag
> "TL" == Tom Lane writes:
TL> Did that packaging guideline get reverted already?
No, it didn't, but of course you know the packaging committee cannot
prevent an upstream from implementing whatever functionality they like.
We can of course revisit the prohibition if someone cares to file a
t
On Wed, Jun 27, 2012 at 12:04 AM, Tom Lane wrote:
> The idea seems to be that you'd only implement actions that exist
> in non-systemd initscripts. As long as people adhere to that,
> I don't see that we need controls or per-package permissions. And
> I don't really see why people wouldn't.
Wel
On Tue, Jun 26, 2012 at 11:48 PM, "Jóhann B. Guðmundsson"
wrote:
> On 06/26/2012 08:49 PM, Miloslav Trmač wrote:
>>
>> The preferred new way is that upstream implements the action in a way
>> that is same across all distributions. Which, in some sense, does not
>> answer your question.
>
>
> Firs
=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?= writes:
> On 06/26/2012 08:49 PM, Miloslav TrmaÄ wrote:
>> The preferred new way is that upstream implements the action in a way
>> that is same across all distributions. Which, in some sense, does not
>> answer your question.
> First and foremos
On 06/26/2012 08:49 PM, Miloslav Trmač wrote:
The preferred new way is that upstream implements the action in a way
that is same across all distributions. Which, in some sense, does not
answer your question.
First and foremost how big of a problem do you guys believe this?
Secondly cant we ad
Bill Nottingham writes:
> Better late than never (and thanks to Michal Schmidt), I've added support to
> /sbin/service for running legacy actions if specified.
I'm confused. Only 2 months ago I was told that this was firmly
against policy and I should get rid of code that assumed it worked
(whic
On 06/26/2012 08:11 PM, Bill Nottingham wrote:
Questions? Comments?
You do realize what you have effectively just done by this dont you?
JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Jun 26, 2012 at 10:45 PM, Till Maas wrote:
>> 2) Don't package a legacy action for new scripts or actions that were not
>> supported by the prior init script; this is intended for compatibility with
>> existing scripts and/or administrator brains.
>
> It would be nice to have a good plan a
On Tue, Jun 26, 2012 at 04:11:19PM -0400, Bill Nottingham wrote:
> BEST PRACTICES
>
> 1) A legacy action of this sort should print to stderr the preferred way to
> accomplish the task, if one is supported.
>
> 2) Don't package a legacy action for new scripts or actions that were not
> supported
On Tue, Jun 26, 2012 at 16:11:19 -0400,
Bill Nottingham wrote:
Questions? Comments?
Thanks!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
THE PROBLEM
We have assorted init scripts that have historically defined custom actions.
Given that this is an unbounded set, it is impossible to handle them
natively in systemd. However, they're usually part of administrators muscle
memory.
Better late than never (and thanks to Michal Schmidt),
26 matches
Mail list logo
