[RFC] plans for initscripts in F22

Miloslav Trmač mitr at volny.cz
Mon Apr 28 16:48:09 UTC 2014


2014-04-26 11:24 GMT+02:00 Michael Scherer <misc at zarb.org>:

> Le vendredi 25 avril 2014 à 19:30 +0200, Miloslav Trmač a écrit :
> > For LSB, there is an explicit promise that if a vendor does what is
> > specified, the package will be possible to install and will run
> > correctly.  We do, of course, have the option to repudiate LSB and
> > explicitly say we don't care for future releases.
>
> So shouldn't redhat-lsb or some subpackage be the one that pull that
> part ?
>

That's a clean solution for the LSB concern, but not for the larger point.
(Honestly this is more a matter of reinforcing the principle than finding a
perfect solution for that specific file.)

> And it's not only commercial software; private projects that make no
> > sense to publish (such as a company's web site) are equally affected
> > such changes. Simply spoken, if we care only about package in Fedora,
> > we are building an appliance; if we want to build an operating system,
> > we do need to cater for software not included directly in the repo.
>
> Then how can we signal to people that they need to update those
> packages ?
>

My opinion is that *in most cases* this is just asking the wrong question;
we shouldn't *need* to signal that.  When old applications correctly using
the API of $os_name stops working, your product is in a very practical
sense *no longer $os_name*.

Because we can as well say "we are gonna support that forever", but that
> will result into bitrot if no one really test.
>

The principled answer to this is to have a comprehensive automated test
suite... which, unfortunately, we don't have.
     Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140428/fa28ca92/attachment.html>


More information about the devel mailing list