Summary: | portage ownership silently renamed | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Geoffrey Clements <geoff> |
Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | strace log |
Description
Geoffrey Clements
2006-07-27 14:39:00 UTC
Assuming you talk about a file that previously existed in ${ROOT}, in that case the behavior is expected, see my comments on bug #141619 (In reply to comment #1) > Assuming you talk about a file that previously existed in ${ROOT}, in that case > the behavior is expected, see my comments on bug #141619 > Thanks for the fast answer. I'm working on a new ebuild, these files didn't exist before (I was testing from a "clean" setup). Also AIUI fowners changes the ownership under ${D} so I ran: ebuild <an_ebuild> install and checked in: /var/tmp/portage/<ebuild>/image/<package>/path/to/file and the file remained at root:root. So it /appears/ that fowners does nothing. Ok, if the file isn't changed in $D this is valid. However given that fowner is just #!/bin/bash # Copyright 1999-2006 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Id: fowners 3483 2006-06-10 21:40:40Z genone $ slash=/ exec chown "${@/#${slash}/${D}${slash}}" I'm not exactly sure how it can go wrong. Does it work if instead of fowners you call chown in your ebuild? (In reply to comment #3) > Ok, if the file isn't changed in $D this is valid. > However given that fowner is just > > #!/bin/bash > # Copyright 1999-2006 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > # $Id: fowners 3483 2006-06-10 21:40:40Z genone $ > > slash=/ > exec chown "${@/#${slash}/${D}${slash}}" > > I'm not exactly sure how it can go wrong. > Does it work if instead of fowners you call chown in your ebuild? > Well there's not much to go wrong there :) Ok - this is really weird, chown does _not_ work when run from the ebuild. However, if I do the chown from the command line immediately after running "ebuild <file.ebuild> install" then that works. I'm running as root here in both cases. Just to make sure that both cases were using exactly the same command I got the ebuild to echo the full chown command to stdout then I used cut and paste to run the command from the command line manually. Maybe privileges are dropped in the ebuild but that's just a guess which is probably not right because I see no error message. In what phase do you try to change the permissions? It should be in src_install, other phases may run with reduced priviledges. (In reply to comment #5) > In what phase do you try to change the permissions? It should be in > src_install, other phases may run with reduced priviledges. > Here's the code: src_install() { PORTCFG=$(python -c 'import portage; print portage.USER_CONFIG_PATH,') || die "Cannot get config path" exeinto /usr/sbin doexe postsync insinto ${PORTCFG}/bin doins bin/post_sync dosed "s:/etc/portage:${PORTCFG}:g" ${PORTCFG}/bin/post_sync insinto /usr/lib/postsync.d doins postsync.d/* fowners root:portage /usr/sbin/postsync ${PORTCFG}/bin/post_sync /usr/lib/postsync.d/* dodoc README ChangeLog doc/* } globing wont work as it is evaluated too early (In reply to comment #7) > globing wont work as it is evaluated too early Dah! - a basic error, thanks for pointing that one out (I must stop hacking after midnight). During testing only fowners root:portage /usr/sbin/postsync was used (in an attempt to keep things simple) so I still have the reported problem. so try doing like: bash -x fowners root:portage /usr/sbin/postsync and if that isnt useful, then try: strace -o log fowners root:portage /usr/sbin/postsync Created attachment 93140 [details]
strace log
(In reply to comment #9) > so try doing like: > bash -x fowners root:portage /usr/sbin/postsync > See attachment # ll /var/tmp/portage/postsync-0.1_alpha/image//usr/sbin/postsync -rwxr-xr-x 1 root root 3377 Jul 31 20:27 /var/tmp/portage/postsync-0.1_alpha/image//usr/sbin/postsync I'm no expert (it's the first time I've used strace) but this looks ok to me and yet the file ownership remains unchanged. Bugger - I screwed up the last post and missed off the bash -x output, here it is: # ebuild postsync-0.1_alpha.ebuild install >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking postsync-0.1_alpha.tar.bz2 ;-) >>> Unpacking source... >>> Unpacking postsync-0.1_alpha.tar.bz2 to /var/tmp/portage/postsync-0.1_alpha/work >>> Source unpacked. >>> Compiling source in /var/tmp/portage/postsync-0.1_alpha/work/postsync ... >>> Source compiled. >>> Test phase [not enabled]: app-portage/postsync-0.1_alpha >>> Install postsync-0.1_alpha into /var/tmp/portage/postsync-0.1_alpha/image/ category app-portage + slash=/ + exec chown root:portage /var/tmp/portage/postsync-0.1_alpha/image//usr/sbin/postsync >>> Completed installing postsync-0.1_alpha into /var/tmp/portage/postsync-0.1_alpha/image/ man: # ll /var/tmp/portage/postsync-0.1_alpha/image//usr/sbin/postsync -rwxr-xr-x 1 root root 3377 Jul 31 20:33 /var/tmp/portage/postsync-0.1_alpha/image//usr/sbin/postsync oh, this is a feature portage silently resets all user/group from "portage" to "root" (In reply to comment #13) > oh, this is a feature > > portage silently resets all user/group from "portage" to "root" > ahh - ok, thanks for your help. Guess this bug can be closed then. you'll have to do it in like pkg_postinst(): chgrp portage "${ROOT}"/usr/bin/postsync |