On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote: > yeah.. I scanned that bug, saw his arguments, but didn't see anything > afterwards that seemed to address his arguments (nor anything that > specifically addressed the removal of /etc/init.d/functions.sh as the > de-facto location).
https://bugs.gentoo.org/show_bug.cgi?id=373219#C74 This is the first point when I proposed moving the file with a good argument and asked vapier to weigh in. Below are several points in the discussion where it was made clear that we were moving the file, and also vapier participated in reviewing alternate implementations. He suggested making this part of baselayout instead of introducing a new package. I asked him to connect with me so we could talk about why he felt that was a good place for it (since I didn't because it may need more maintenance than baselayout does). That connect never happened for whatever reason. https://bugs.gentoo.org/show_bug.cgi?id=373219#C93 https://bugs.gentoo.org/show_bug.cgi?id=373219#C95 https://bugs.gentoo.org/show_bug.cgi?id=373219#C96 https://bugs.gentoo.org/show_bug.cgi?id=373219#C116 https://bugs.gentoo.org/show_bug.cgi?id=373219#C119 https://bugs.gentoo.org/show_bug.cgi?id=373219#C120 https://bugs.gentoo.org/show_bug.cgi?id=373219#C124 > > 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. 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. > >> Also, just to confirm, this new path is compatible with the > >> einfo package used as part of Prefix, yes? Or other arrangements > >> have been made (ie, the einfo package will be dropped from > >> baselayout-prefix)? > > > > No one has said anything to me about prefix so I don't know what > > they want to do. To be honest I would prefer that they drop einfo. > > unless there is a good reason for them not to. > > This is something that should probably be managed, then, before the > migration to gentoo-functions is completed -- anyone here from th > prefix team, that wants to weigh in? Will gentoo-functions work in > prefix (well enough to replace einfo)? https://bugs.gentoo.org/show_bug.cgi?id=504284 William
signature.asc
Description: Digital signature
