Re: [gentoo-dev] gentoo-functions is in the tree

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/03/14 09:10 PM, William Hubbs wrote:
> On Tue, Mar 11, 2014 at 10:10:42AM -0400, Ian Stakenvicius wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> On 10/03/14 07:30 PM, William Hubbs wrote:
>>> All,
>>>
>>> for bug 373219 [1], we are working on providing a functions.sh
>>> that does not rely on OpenRc so that people who are not using
>>> OpenRc can completely remove it from their systems.
>>>
>>> I can now report that gentoo-functions has been added to the
>>> tree. Also, I have opened a tracker [2] that explains how to
>>> change packages that source /etc/init.d/functions.sh. They
>>> should first check for the existence of
>>> /lib/gentoo/functions.sh and source that. If it doesn't exist,
>>> they should source /etc/init.d/functions.sh. Also, do not add
>>> hard dependencies to your packages on gentoo-functions. The
>>> goal is to add gentoo-functions to @system once it is stable.
>>>
>>> The quickest way to find things that will need this fix is to
>>> rm /etc/init.d/functions.sh and file bugs against things that
>>> break and make them block the tracker.
>>>
>>
>> - From what I remember about conversations on this in the past,
>> and hopefully vapier can confirm, the de-facto location for this
>> script is supposed to be /etc/init.d/functions.sh.  Was there a
>> general consensus on the approval of that location change?  I
>> still think, at worst, we should ensure the gentoo-functions
>> script installs a symlink here (possibly taking over the one
>> installed by openrc, if openrc still installs one)
>
> This was discussed at length on the bug. After multiple people
> presented arguments supporting changing this location, vapier was
> given ample time to weigh in with reasons that we shouldn't change
> it. He did not, so it has been changed [1].
>

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).

Don't get me wrong, i think it is very pertinent to install the actual
"lib" elsewhere, but since this is still the de-facto location we
should have a symlink.


> 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)

>> 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)?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlMgXdIACgkQ2ugaI38ACPCseAD/VLbvGkzN53hx8Z0C9xOHlJxe
VOZu39w+HQhVa5V6vGMA/A+zmmnKjMV1pqJSgCJhgClBu7Ms9QeauZKcvjeKddqx
=Ozpu
-----END PGP SIGNATURE-----