Skrypty startowe mldonkey

Mariusz Mazur mmazur at kernel.pl
Mon Dec 14 11:08:30 CET 2015


(Sorry for the delay, weekend is mostly computer-less.)

On Fri of December 11 2015, Tomasz Pala wrote:

> > On Fri, Dec 11, 2015 at 13:44:03 +0100, Mariusz Mazur wrote:
> > Somebody needs it, somebody does it.
> 
> When sb needs to break compatibility he is allowed to do so? Seriously?

The way I see it there are usually are two options in cases like this:
1. Evolution of core scripts/libraries is acceptable even if it has wide-
reaching consequences because we always have the option of mass commits to all 
affected packages to make sure everything keeps working.
2. However the above does not hold true for cases were compatibility with 
external apps is important. Here even a mass commit is not able to fix enough 
of the problem.

The way I see it sysv init scripts will be primarily used for dealing with 
legacy software, which means compatibility with most/all of external packages 
is important and should not be broken. It should even be explicitly pursued.

At the same time glen obviously has ongoing use cases, otherwise he wouldn't 
have a reason to look at rc-scripts (I believe he mentioned vserver).

I think that the prefered solution here would be to:
1. Explicitly set a goal for all of the common sysv functions (like 'daemon') 
to be as widely compatible as possible and only make changes to them to 
increase said compatibility.
2. For our developers' purposes have our own set of functions we're free to 
not care about external/legacy software compatibility ('daemon2' or 
'pld_extreme_daemon' or something) and can keep on evolving them for whatever 
it is we need at a given time.

Does anybody have an issue with such an approach?


--mmazur


More information about the pld-devel-en mailing list