(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
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
