Portage's build system depends on coreutils because of `install -t`. I encountered that dependency when I tried omitting coreutils from stage1 of the Gentoo Prefix bootstrap procedure in an attempt to workaround bug #415439. At present, portage's use of `install -t` seems to be the only dependency on coreutils that stage 1 of the Gentoo Prefix boostrap procedure has. Stage 1 compilation of coreutils tends to break on exotic platforms, such as Minix and Cygwin. It would be helpful in those situations if portage's build system did not depend on `install -t`. That could enable stage2 of the installation to proceed, at which point, patches from the portage tree would be available to fix issues in the build system. An example of this would be the following from a Gentoo Prefix install on Gentoo FreeBSD, where the coreutils step of stage 1 of the bootstrap procedure was omitted: /usr/bin/install -c -m 644 -m 755 -o richard -g richard -t /home/richard/delme/usr/lib/portage/bin/. ././archive-conf ././banned-helper ././bashrc-functions.sh ././binhost-snapshot ././check-implicit-pointer-usage.py ././chpathtool.py ././clean_locks ././dispatch-conf ././dohtml.py ././ebuild ././ebuild-ipc ././ebuild-ipc.py ././ebuild.sh ././egencache ././emaint ././emerge ././emerge-webrsync ././env-update ././etc-update ././filter-bash-environment.py ././fixpackages ././glsa-check ././isolated-functions.sh ././lock-helper.py ././misc-functions.sh ././phase-functions.sh ././phase-functions.sh.rej ././phase-helpers.sh ././portageq ././quickpkg ././readpecoff ././regenworld ././repoman ././save-ebuild-env.sh ././xpak-helper.py install: illegal option -- t usage: install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode] [-o owner] file1 ... fileN directory install -d [-v] [-g group] [-m mode] [-o owner] directory ... Writing that command (and those like it) in the following manner would avoid this: /usr/bin/install -c -m 644 -m 755 -o richard -g richard ././archive-conf ././banned-helper ././bashrc-functions.sh ././binhost-snapshot ././check-implicit-pointer-usage.py ././chpathtool.py ././clean_locks ././dispatch-conf ././dohtml.py ././ebuild ././ebuild-ipc ././ebuild-ipc.py ././ebuild.sh ././egencache ././emaint ././emerge ././emerge-webrsync ././env-update ././etc-update ././filter-bash-environment.py ././fixpackages ././glsa-check ././isolated-functions.sh ././lock-helper.py ././misc-functions.sh ././phase-functions.sh ././phase-functions.sh.rej ././phase-helpers.sh ././portageq ././quickpkg ././readpecoff ././regenworld ././repoman ././save-ebuild-env.sh ././xpak-helper.py /home/richard/delme/usr/lib/portage/bin
One of the basic assumptions of Gentoo Prefix is a GNU userland. To workaround that seems error prone, unless the basic assumption is re-evaluated (not going to happen)
(In reply to comment #1) > One of the basic assumptions of Gentoo Prefix is a GNU userland. To > workaround that seems error prone, unless the basic assumption is > re-evaluated (not going to happen) Many of the ebuilds involved are shared with Gentoo FreeBSD, which does not use a GNU userland. That provides a degree of portability that could be leveraged to workaround issues during the stage 1 phase of the bootstrap procedure, which there is no such assumption and there are also very few patches. If there are issues building coreutils during stage 1, then a viable workaround could be to proceed to stage 2 and build coreutils there, which would apply patches from the portage tree. It seems that the main thing preventing this is a dependency that the prefix portage branch introduces on coreutils in its build system. With that said, bug #415439 describes a situation where the bootstrap procedure fails on a system built from the main portage tree. It would seem reasonable to be able to omit most of the steps in the stage 1 phase, including the coreutils step that currently causes a bootstrap failure. What is installed at the end of stage 3 would be the same regardless of whether these steps are omitted or not.
People have resigned from Gentoo in the past just because we didn't want to make ebuilds POSIX shell scripts. Prefix has the virtue of using a GNU userland, that is, being compatible with the biggest part of the developer base. This is not going to change, like Jeremy said. I don't feel like changing this, coreutils is necessary anyway. x64-freebsd profile should define USERLAND=GNU, hence install being part of coreutils.
(In reply to comment #3) > Prefix has the virtue of using a GNU userland, that is, being compatible > with the biggest part of the developer base. This is not going to change, > like Jeremy said. > > I don't feel like changing this, coreutils is necessary anyway. x64-freebsd > profile should define USERLAND=GNU, hence install being part of coreutils. This is a build system dependency on a GNU-extension to a BSD command. Merging changes in the prefix branch into portage could unexpectedly break Gentoo/FreeBSD if it is not removed.
unlikely to ever happen, so not an issue
