I use the buildpkg/usepkg functionality to distribute standardized software to a half-dozen servers, but the new baselayout breaks this functionality. In pkg_postinst() the ebuild tries to copy /etc/conf.d/rc and /etc/inittab from the build directory, but since the build directory is not on my client servers -- it does not work. Reproducible: Always Steps to Reproduce: 1. "emerge -pub baselayout" on gentoo package server 2. "emerge -puk baselayout" on gentoo package client Actual Results: cat: /tmp/portage/baselayout-1.8.6.8-r1/temp/ROOT: No such file or directory * Backing up your old /etc/conf.d/rc, and replacing with new! * This is needed, as $svcdir moved from /mnt/.init.d to * /var/state/init.d cp: cannot stat `/tmp/portage/baselayout-1.8.6.8-r1/work/rc-scripts-1.4.3.8p1//etc/conf.d/rc': No such file or directory * Backing up your old /etc/inittab, and replacing with new! * This is needed, as there were critical changes to /sbin/rc cp: cannot stat `/tmp/portage/baselayout-1.8.6.8-r1/work/rc-scripts-1.4.3.8p1//etc/inittab': No such file or directory Expected Results: A better design would make backups in pkg_preinst() and then let the files be installed as normal. There should be no expectation of the existance of the builddir during the installation phase.
I've been bitten by this error and at least one other error with another ebuild with the same root cause: the ebuild refers to files during the install that aren't in the binary package. I'd like to see portage modified to generate a sandbox error if any of the install rules (including preinst and postinst) refer to any file down in the temp or work dirs. This would prevent developers from successfully creating an ebuild that violates this rule of proper package creation in the future.
Please read the comments in the ebuild.
I can accept that this package cannot be package friendly -- it is a critical low level package. But in looking at the package there doesn't seem to be any particular need for the ebuild to not be package friendly. The only unfriendliness that I saw was the attempt to copy the /etc/conf.d/rc and /etc/inittab files from the build directory (${S}) if you don't want to do the backups in pkg_preinst(), why not "install" the files to /tmp/etc/... then in pkg_postinst() move the files to /etc/. Aside from this minor issue is there another reason why this ebuild cannot be package safe? The comments in the ebuild give no indication as to why. A second issue is if an ebuild is not package safe portage should not be able to create a package of it.... Not trying to be difficult, jbw
Merely having a comment in an ebuild that it is not compatible with binary packages is no where near good enough to prevent people from screwing up their systems. I think the minimal change would be to modify baselayout so that if the user attempts to install a baselayout package, it fails (at the start). The current package installs with errors (that scroll by without stopping the ebuild), and the resulting machine is no longer capable of rebooting to a useful state (no logins are possible -- I can to boot from CD, mount all my partitions, and do a "live" emerbe of baselayout in a chroot jail to get my system back to a useful state). Seems to me that the easiest way to prevent such system corruption would be to add a check to the pkg_preinst() section that dies if we notice that the expected portage-tmp files are not there.
