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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

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.

If you have any questions, let me know.

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=373219
[2] https://bugs.gentoo.org/show_bug.cgi?id=504116

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ian Stakenvicius]

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

That said, I'm certainly fine with having all package-installed
scripts use the /lib/ location and depending directly on this new package.

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




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

iF4EAREIAAYFAlMfGWIACgkQ2ugaI38ACPCZhAD/aaM1e12lf86YWqCzS0RPvrRo
XGc5zLlykr/lY4cix5sA/RWn42uEK1kjQKfsWm+gtxzw7PUGVSUQemXG10FJMJ0R
=eUAw
-----END PGP SIGNATURE-----

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

Dnia 2014-03-10, o godz. 18:30:29
William Hubbs <williamh@gentoo.org> napisał(a):

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

Why? I'm pretty sure we were working on having more explicit deps
and less @system magic. This goes exactly the opposite way.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Rich Freeman]

On Tue, Mar 11, 2014 at 1:54 PM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2014-03-10, o godz. 18:30:29
> William Hubbs <williamh@gentoo.org> napisał(a):
>
>> 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.
>
> Why? I'm pretty sure we were working on having more explicit deps
> and less @system magic. This goes exactly the opposite way.

++

Why not install it in the same place as openrc, create a virtual, and
have the two block?  Or move the file from openrc to the new package
and have openrc depend on it (probably a cleaner solution if you can
handle the transition)?

I definitely see the FHS logic in moving it out of /etc, though a
compatibility symlink should probably be maintained for some time.
I'm not sure about the config-protection implications of replacing a
file with a symlink offhand - that might require a bit of special
handling.

Packages should depend on whatever provides the script (either the
virtual or the package depending on the approach chosen), but in the
interim openrc or the virtual will be in the system set.

Rich

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

[Ian Stakenvicius]

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

On 11/03/14 02:24 PM, Rich Freeman wrote:
> On Tue, Mar 11, 2014 at 1:54 PM, Michał Górny <mgorny@gentoo.org>
> wrote:
>> Dnia 2014-03-10, o godz. 18:30:29 William Hubbs
>> <williamh@gentoo.org> napisał(a):
>> 
>>> 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.
>> 
>> Why? I'm pretty sure we were working on having more explicit
>> deps and less @system magic. This goes exactly the opposite way.
> 
> ++
> 

++ , it makes no sense to not explicitly depend on this, when a
package needs it.  That's one of the reasons why things that use
functions.sh now fail when openrc wassn't installed (openrc being the
provider, until now).



> Why not install it in the same place as openrc, create a virtual,
> and have the two block?  Or move the file from openrc to the new
> package and have openrc depend on it (probably a cleaner solution
> if you can handle the transition)?

Eww, no.  This is a bash script; the C internal functions that are in
openrc already are way better for openrc to use.  However, yes, both
of these packages should be able to be installed at the same time.

(note, there was a short discussion about separating einfo/libeinfo
into its own package and having openrc depend on it, but it was
rejected.  if -that- happened then it would make more sense to go this
direction)



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

iF4EAREIAAYFAlMfX5gACgkQ2ugaI38ACPCMzgD8DFPnA1JT0BGVE9nSgsEoqoo8
LGl4Nb9i7Q7Rewd1yZIBAJcIWP5kI9e4Wl//+O21+O7gfl7LSHnAmYxW97zDsGfm
=OpiU
-----END PGP SIGNATURE-----

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

On Tue, Mar 11, 2014 at 03:10:16PM -0400, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 11/03/14 02:24 PM, Rich Freeman wrote:
> > On Tue, Mar 11, 2014 at 1:54 PM, Michał Górny <mgorny@gentoo.org>
> > wrote:
> >> Dnia 2014-03-10, o godz. 18:30:29 William Hubbs
> >> <williamh@gentoo.org> napisał(a):
> >> 
> >>> 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.
> >> 
> >> Why? I'm pretty sure we were working on having more explicit
> >> deps and less @system magic. This goes exactly the opposite way.
> > 
> > ++
> > 
> 
> ++ , it makes no sense to not explicitly depend on this, when a
> package needs it.  That's one of the reasons why things that use
> functions.sh now fail when openrc wassn't installed (openrc being the
> provider, until now).

We can go that route, then not bother adding it to @system at all. I was
just thinking that it will be needed everywhere, and since it is,  it
would be a good candidate for @system.

> > Why not install it in the same place as openrc, create a virtual,
> > and have the two block?  Or move the file from openrc to the new
> > package and have openrc depend on it (probably a cleaner solution
> > if you can handle the transition)?
> 
> Eww, no.  This is a bash script; the C internal functions that are in
> openrc already are way better for openrc to use.  However, yes, both
> of these packages should be able to be installed at the same time.

Also, if we want to make systems completely clean for folks who aren't
using OpenRc, we shouldn't put anything in /etc/init.d besides init
scripts. That way, someone can add /etc/init.d and possibly /etc/conf.d
to INSTALL_MASK and have a clean setup without OpenRc.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]

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

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.

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

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=373219
[2] http://www.semver.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3126 bytes --]

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ian Stakenvicius]

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

On 10/03/14 07:30 PM, William Hubbs wrote:
> 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.

..is there a tracker bug currently?  I did a search but I didn't see
anything in particular.  It doesn't seem right to use the main bug
373219 ...



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

iF4EAREIAAYFAlMgkxUACgkQ2ugaI38ACPArRwD9GpFiGgI9K6YwYgWPzaUD9trX
7WFyEXPYvLWZqB9YHgkBAIMnKJVki5M++EuU0AgSbcef0074+eeUixG/v/xcokRK
=Hfde
-----END PGP SIGNATURE-----

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

[Ian Stakenvicius]

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

On 12/03/14 12:52 PM, William Hubbs wrote:
> 
> 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.


Perfect.  So long as that path remains intact from the perspective of
gentoo's end-users.

Thanks!

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

iF4EAREIAAYFAlMgkzYACgkQ2ugaI38ACPBEQgD/W46QG4tmqFLGQtwCeBgKkwZp
QwvsgrGr4UK9SpiM/6ABAL+OStinQ3PYskf+CdmoCXl6lIsCcMYfifmJ5La56N4s
=kXCH
-----END PGP SIGNATURE-----

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

[Rich Freeman]

On Wed, Mar 12, 2014 at 12:52 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote:
>> ...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.
>

If the goal is to be able to remove openrc from systems, how does it
help that we might fix any breakage after openrc no longer provides
it?

If the goal is to be able to remove openrc from systems, then
something else needs to provide the symlink.  I guess in the meantime
users could just remove openrc and just manually install the symlink,
but that isn't really a clean solution.

Otherwise openrc can't be removed until anything that sources this is
fixed.  If it all does get fixed, then the symlink isn't even needed
(though I suppose openrc can still provide it for any other distros
that use it).

Rich

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]

On Wed, Mar 12, 2014 at 01:08:43PM -0400, Rich Freeman wrote:
> On Wed, Mar 12, 2014 at 12:52 PM, William Hubbs <williamh@gentoo.org> wrote:
> > On Wed, Mar 12, 2014 at 09:14:58AM -0400, Ian Stakenvicius wrote:
> >> ...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.
> >
> 
> If the goal is to be able to remove openrc from systems, how does it
> help that we might fix any breakage after openrc no longer provides
> it?

I don't follow this question.

> If the goal is to be able to remove openrc from systems, then
> something else needs to provide the symlink.  I guess in the meantime
> users could just remove openrc and just manually install the symlink,
> but that isn't really a clean solution.
> 
> Otherwise openrc can't be removed until anything that sources this is
> fixed.  If it all does get fixed, then the symlink isn't even needed
> (though I suppose openrc can still provide it for any other distros
> that use it).

Here is what I'm going to do inside openrc:

/etc/init.d/functions.sh, which is a symlink now, will become an actual
script that does the following:

source "@LIBEXECDIR@"/sh/functions.sh
ewarn "$0: sourcing /etc/init.d/functions.sh is deprecated."
ewarn "This file will be removed in a future version of OpenRc, so please"
ewarn "source \"@LIBEXECDIR@\"/sh/functions.sh if you need this functionality."

Where @LIBEXECDIR@ is replaced at build time with OpenRc's libexecdir
setting.

From the gentoo side, when bugs are filed, the maintainers will have to
make a decision about whether to source /lib/gentoo/functions.sh or
@LIBEXECDIR@/sh/functions.sh based on whether their package really needs
OpenRc specific functionality or not.

Gentoo end users who are sourcing /etc/init.d/functions.sh will have to
make the same decision.

Non-gentoo end users will know what they have to do -- fix
their scripts to  source @LIBEXECDIR@/sh/functions.sh.

So, I am having trouble seeing why the symlink will be needed at all
after OpenRc removes this script in OpenRc 1.0.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Tom Wijsman]

On Wed, 12 Mar 2014 13:02:13 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 10/03/14 07:30 PM, William Hubbs wrote:
> > 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.
> 
> ..is there a tracker bug currently?

https://bugs.gentoo.org/show_bug.cgi?id=504116

Alias: functions.sh

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]

On Wed, Mar 12, 2014 at 01:02:13PM -0400, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 10/03/14 07:30 PM, William Hubbs wrote:
> > 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.
> 
> ..is there a tracker bug currently?  I did a search but I didn't see
> anything in particular.  It doesn't seem right to use the main bug
> 373219 ...

http://bugs.gentoo.org/show_bug.cgi?id=504116

I thought I mentioned it earlier in the thread; sorry about that.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

All,

thinking about this further,

There may not be a need to remove /etc/init.d/functions.sh as long as it
is understood that this is part of OpenRc, not the gentoo base.

In other words, tools that must work when OpenRc is not present should
source /lib/gentoo/functions.sh, NOT /etc/init.d/functions.sh.

What are your thoughts on this approach?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ian Stakenvicius]

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

On 12/03/14 03:59 PM, William Hubbs wrote:
> All,
> 
> thinking about this further,
> 
> There may not be a need to remove /etc/init.d/functions.sh as long
> as it is understood that this is part of OpenRc, not the gentoo
> base.
> 
> In other words, tools that must work when OpenRc is not present
> should source /lib/gentoo/functions.sh, NOT
> /etc/init.d/functions.sh.
> 
> What are your thoughts on this approach?
> 
> William
> 


Well, this will leave the de-facto path intact for the majority of
users, which sounds great to me.

This path -wont- be available for users that don't have openrc
installed, but then, if all of the tools in portage are converted to
use /lib/gentoo/functions.sh this probably won't matter -- i dont
think many custom script writers using a systemd system will care
about output consistency with openrc anyhow.


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

iF4EAREIAAYFAlMgwZoACgkQ2ugaI38ACPDcPgEAhSkoJma2GVfUeKpRoIcvHEQD
tivcbFdpHRF3xTtssUYA/RXQvFCkwyqiALsu1Jm94fGTsjT1aCHxYA96oefY++Fv
=Vu5p
-----END PGP SIGNATURE-----

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

[Patrick McLean]

On Thu, 13 Mar 2014 07:59:55 +0800
Patrick Lauer <patrick@gentoo.org> wrote:

> On 03/13/2014 12:52 AM, William Hubbs wrote:
> 
> 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!")
> 

I would say it's because library code such as that really does not
belong in /etc and placing it there in the first place was a mistake.
This is an attempt to correct the mistake without just breaking
everything without warning.

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

[Patrick Lauer]

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

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

[Joshua Kinard]

On 03/12/2014 7:59 PM, Patrick Lauer wrote:
> 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!")

Maybe we should write another script for OpenRC that, at each boot,
determines a random location in your filesystem and moves
/etc/init.d/functions.sh there, but moves it back on system shutdown.  It'll
also go through all scripts that source functions.sh and update them to
point at the new, random location, each time.

We'll also need a type of openrc-fsck script that handles cases of unclean
shutdowns that don't move the file back to /etc (or /lib, or both).

Now that's innovation!

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

Dnia 2014-03-13, o godz. 07:59:55
Patrick Lauer <patrick@gentoo.org> napisał(a):

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

See: http://article.gmane.org/gmane.linux.gentoo.project/3357

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Mike Gilbert]

On Mon, Mar 10, 2014 at 7:30 PM, William Hubbs <williamh@gentoo.org> 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.

After reading some posts further in this thread, and discussing on IRC
with William, I decided to do the following with
app-admin/python-updater-0.12:

1. Changed . /etc/init.d/functions.sh to . /lib/gentoo/functions.sh.
This way I don't need to worry about testing against two different
implementations.

2. Added a hard dependency on sys-apps/gentoo-functions. Being
explicit about dependencies is better than leaving it up to the
implicit @systemd dependency.

If someone has a really good argument for why I should instead
implement this as William originally described above, I am open to
changing my approach.

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

On Sun, Mar 16, 2014 at 09:36:02PM -0400, Mike Gilbert wrote:
> On Mon, Mar 10, 2014 at 7:30 PM, William Hubbs <williamh@gentoo.org> 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.
> 
> After reading some posts further in this thread, and discussing on IRC
> with William, I decided to do the following with
> app-admin/python-updater-0.12:
> 
> 1. Changed . /etc/init.d/functions.sh to . /lib/gentoo/functions.sh.
> This way I don't need to worry about testing against two different
> implementations.
> 
> 2. Added a hard dependency on sys-apps/gentoo-functions. Being
> explicit about dependencies is better than leaving it up to the
> implicit @systemd dependency.
> 
> If someone has a really good argument for why I should instead
> implement this as William originally described above, I am open to
> changing my approach.

After this discussion with Mike, and the comments in this thread, it is
probably better to do this -- refer to /lib/gentoo/functions.sh instead
and make your package have a hard dependency on gentoo-functions.

Keep in mind that this applies only to packages that need to run with
OpenRC not being on the system.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]