prefix team: We now have a simple shell script, sys-apps/gentoo-functions, which implements the e* functions used by tools outside of OpenRc. I am asking you to consider removing the einfo package from baselayout-prefix and using gentoo-functions instead. The script puts this file in /lib/gentoo/functions.sh which means that some migration will have to happen. The ebuild uses eapi 5, so it is already prefix aware. The migration is already starting to happen on bug #504116. Do you have any thoughts on this for prefix? Thanks, William
This surely is on the radar! We need to try and see what happens. I hope the implementation is not relying on paths and all that stuff to fine tools.
Also, more specifically, since the various tools (outside of openrc) that currently use /etc/init.d/functions.sh are going to be migrated to use the new gentoo-functions' /lib/gentoo/functions.sh (and so the functions.sh einfo provides won't even be used by these tools), we need to get confirmation that gentoo-functions will work in prefix. Given it is a shell script and afaik a POSIX sh (or perhaps even bash itself) is a hard dependency of a prefix install, there is probably no reason why it wouldn't work; confirmation would still be appreciated. :)
This looks like it is no problem at all. sys-apps/gentoo-functions is perfectly prefix compatible, and there shouldn't be bootstrapping problems either. The only question is whether there are any packages using einfo.h or libeinfo.so, but I rather doubt that is the case. Unless the above is the case, prefix should be able to switch without any problems once the tracked tools are migrated.
(In reply to Ruud Koolen from comment #3) > This looks like it is no problem at all. sys-apps/gentoo-functions is > perfectly prefix compatible, and there shouldn't be bootstrapping problems > either. > I assume we would want to use @GENTOO_PORTAGE_PREFIX@ / eprefixify in any consumers (like python-updater)?
*** Bug 504422 has been marked as a duplicate of this bug. ***
*** Bug 504428 has been marked as a duplicate of this bug. ***
*** Bug 504424 has been marked as a duplicate of this bug. ***
*** Bug 504426 has been marked as a duplicate of this bug. ***
(In reply to Mike Gilbert from comment #4) > (In reply to Ruud Koolen from comment #3) > > This looks like it is no problem at all. sys-apps/gentoo-functions is > > perfectly prefix compatible, and there shouldn't be bootstrapping problems > > either. > > > > I assume we would want to use @GENTOO_PORTAGE_PREFIX@ / eprefixify in any > consumers (like python-updater)? Yes, as well as that gentoo-functions should use that itself to specify the bash/sh shell it uses. POSIX shell != /bin/sh no matter how hard you try in Prefix.
(In reply to Fabian Groffen from comment #9) > (In reply to Mike Gilbert from comment #4) > > (In reply to Ruud Koolen from comment #3) > > > This looks like it is no problem at all. sys-apps/gentoo-functions is > > > perfectly prefix compatible, and there shouldn't be bootstrapping problems > > > either. > > > > > > > I assume we would want to use @GENTOO_PORTAGE_PREFIX@ / eprefixify in any > > consumers (like python-updater)? > > Yes, as well as that gentoo-functions should use that itself to specify the > bash/sh shell it uses. POSIX shell != /bin/sh no matter how hard you try in > Prefix. Gentoo-functions.sh is not a standalone script, It gets sourced, so it doesn't specify the shell it uses.
I've keyworded gentoo-functions, I guess now is the time to wait for everything to be converted, then remove einfo from baselayout-prefix in a revbump or something?
(In reply to William Hubbs from comment #0) > prefix team: > We now have a simple shell script, sys-apps/gentoo-functions, which > implements the e* functions used by tools outside of OpenRc. because this has apparently emerged into some C-code, I've "fixed" 0.8 to provide a simple shell script for consoletype to get this compiling on our platforms.
baselayout-prefix-2.2-r4 now depends on gentoo-functions to provide /etc/init.d/functions.sh (backwards compat symlink).