On 03/13/2014 12:52 AM, William Hubbs wrote:
>>> No, I don't think gentoo-functions should take over the symbolic
>>> link in /etc/init.d/functions.sh; that needs to stay with OpenRc.
>>> My plan there is to work that into a script that prints a warning
>>> message. It will stay that way until openrc-1.0. OpenRc upstream
>>> uses semantic versioning [2]. This means that as long as we are at
>>> 0.x we have to keep things backward compatible.
>>>
>>
>> ...why not? As you've said yourself, nothing related to openrc uses
>> /etc/init.d/functions.sh; if everything else in the tree is going to
>> use the new gentoo-functions "lib", why wouldn't custom end-user
>> scripts too?
>>
>> (again, scanned the bug, didn't see anything relevant to this)
>
> The relevance is that /etc/init.d/functions.sh is currently part of
> OpenRc's public API, and semantic versioning has a very specific
> description of how to deprecate functionality.
Why deprecate it?
I'm getting really irritated with the current trend of randomly renaming
and movearounding things. All it does is confuse people, break existing
setups and make documentation splitbrained (now you need to document two
things, and half the old docs won't be aware of it ...)
So I guess it boils down to "What does the /usr movearounding gain us",
err, what does renaming bits of OpenRC improve?
The best explanations so far I've seen are "it's nicer", "we've already
done it" and "eh mate, why not? is groovy"
> If Gentoo needs the symlink after it is removed from OpenRc, I think
> that is the time we can talk about putting it in gentoo-functions.
Now that is funny, but why move it away just so that users panic and
re-add the wrong flavour of it?
Well, progress I guess: If you change enough things in trivial ways you
can claim innovation and show a great rate of change ("I'm not dead yet!")
grmblgrrrrr,
Patrick
