When doing a 'FEATURES="buildpkg" emerge tenshi', it seems that pkg_preinst() is called *after* the package is built. emerge then uses this package and merges its content into /, resulting in the ownership root:root for /etc/tenshi/tenshi.conf and /var/lib/tenshi/ (and not tenshi:root as pkg_preinst() should fix it with the fowners commands). Reproducible: Always Steps to Reproduce: 1. FEATURES="buildpkg" emerge tenshi 2. ls -l /etc/tenshi/tenshi.conf /var/lib/ 3. /etc/init.d/tenshi start Actual Results: 1. emerge tenshi 2. ls -l /etc/tenshi/tenshi.conf /var/lib/ 3. /etc/init.d/tenshi start * Starting tenshi... [ERROR] could not open configuration file /etc/tenshi/tenshi.conf: Permission denied After fixing the permissions of /etc/tenshi/tenshi.conf: * Starting tenshi... [ERROR] could not open pid file /var/lib/tenshi/tenshi.pid: Permission denied Expected Results: Start normally (as when doing a 'FEATURES="-buildpkg" emerge tenshi'). Portage 2.0.51-r3 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r2-eden1 x86_64) ================================================================= System uname: 2.6.10-gentoo-r2-eden1 x86_64 AMD Athlon(tm) 64 Processor 2800+ Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-march=athlon64 -mtune=athlon64 -mmmx -m3dnow -msse -msse2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -mtune=athlon64 -mmmx -m3dnow -msse -msse2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg candy ccache digest distlocks sandbox userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.gentoo.mesh-solutions.com/gentoo/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 acpi acpi4linux apache2 bash-completion berkdb cle266 crypt cyrus dvd ethereal fbcon freetype gd gpm hardenedphp idea imap jpeg maildir md5sum mpi multilib ncurses nls nptl offensive pam perl png python readline samba sasl ssl tiff truetype unicode usb xml xml2" Although the info output is from an amd64 box, this problem affects both an amd64 and a x86 system here (and probably other architectures as well).
from ebuild(5): pkg_preinst pkg_postinst All modifications required on the live-filesystem before and after the package is merged should be placed here. Also commen- tary for the user should be listed here as it will be displayed last. Initial working directory of $PWD. From that it should be clear that pkg_preinst is called after the package is built, so that isn't a bug. The question now is what's the real bug: - pkg_preinst isn't called at all - $D is set incorrectly - something else Although personally I'd suggest to put enew* in pkg_setup and fowners in src_install anyway.
I agree with your interpretation that pkg_preinst() is called after building a package and before merging the package into / (package used as "software package"). Unfortunately it doesn't really specify where in this process a binary package is created. Right now it seems that emerge does something like this: ebuild <...> unpack compile ebuild <...> install [ Create the binary package ] [ Call pkg_preinst(), changing the ownership ] [ Merge the binary package, without the changes from pkg_preinst() ] [ Call pkg_postinst() ] ... Personally, I would have expexted that creating the binary and merging it into the filesystem are done immediately one after the other, without a function call inbetween that can (and in this case does) change the image of the package. About your other points: - I inserted my own debug ewarns into all functions, they are called alright. - Don't know about ${D}, but the ownership is wrong in the .tbz2 binary package (root:root), which is then merged into the filesystem. But when doing a 'FEATURES="-buildpkg" ebuild <...> unpack compile install', I verified that the correct ownership is indeed set in /var/tmp/portage/tenshi-0.3.2/image/. And about your way of fixing the ebuild, I came across that one, too, while doing my bug hunting. That's why I filed such a detailed bug report, so that someone with more knowledge can decide whether the problem lies with emerge or with tenshi's ebuild. ;-)
I checked the qmail ebuilds and they chown stuff in pkg_postinst. *shrug* can you add these to pkg_postinst and let me know if it works ok then? chown tenshi:root /etc/tenshi/tenshi.conf chown tenshi:root /var/lib/tenshi
Doing this in pkg_postinst() works fine (as I'd have expected) but that is changing the ownership after the package has been merged into the live filesystem (which, IMO, is bad design). The original ebuild used fowners calls to change the files in the image, before it was merged. The problem with that approach is that emerge seems to build a binary package, then calling pkg_preinst() and then merging the (unchanged) binary package into the filesystem, while the changes to the image are lost (also see comment #2 for more details). So, while it is easy to work around this in the tenshi ebuild (e.g. by calling fowners in src_install after 'make install'), the question remains: is this a bug with portage? IMO it is, because tenshi's image is changed and these changes are lost when emerge merges the binary package. I would have expected that the binary package and the image are completely identical, making no difference which one is merged into the filesystem. But obviously, they are different and it makes a difference.
${D} is not necessarily valid around the install stage. ${IMAGE} is though and is for both sources and binaries.
OK, regarding the permissions, this package is completely useless for me, b/c all my /var/log/*.log permissions are set to 0600 root:root I am using syslog-ng.
Regarding the validity of ${D} in comment #5: ${D} is not used in tenshis ebuild, the lines which trigger this bug are in pkg_preinst(): 'fowners tenshi:root /etc/tenshi/tenshi.conf fowners tenshi:root /var/lib/tenshi'. And I just confirmed it again, the image is correctly created when emerging tenshi (meaning the ownership of the two above mentioned files is in fact tenshi:root *in the image*). Unfortunately, the binary tbz2 package (created using FEATURES="buildpkg" during the very same emerge where I checked on the files in ${IMAGE}) is *not*, resulting in the ownership root:root in the tbz2. Now this tbz2 is merged into /, resulting in tenshi not being able to read its config file (and even if it wasn't and the ${IMAGE} would be merged, the tbz2 would be useless for a later 'emerge --usepkg tenshi' which is the reason I build binary packages in the first place :( ).
Jacub, this bug has nothing to do with the permissions of your log files, these can easily be changed by syslog-ng (and are definitely not a problem of tenshi). Have a look at syslog-ng's documentation or at the supplied sample conf from Debian to see how to do it.
This has to do with $D as fowners uses $D
Now that brought me on the right track ... After another test ('emerge --usepkgonly tenshi') I realised that pkg_preinst() was also called when the tbz2 was merged. But in this case, the fowners call had no ${D} to change file ownerships in, so the tbz2 package was merged with the wrong ownerships. Seeing this, I'd say that pkg_preinst() is not the place for fowners. Now, could someone please assign this to the tenshi maintainers, so the ebuild cann be corrected to work with 'buildpkg'? Thanks.
Created attachment 48899 [details, diff] Patch to the tenshi-0.3.2.ebuild to work correctly when building binary packages This implements the changes suggested in comment #1, making the tenshi ebuild behave correctly when a binary package is created (either via FEATURES="buildpkg" or 'emerge --buildpkg[only] tenshi').
commited, ta
