On Mon, 27 Oct 2014, Michael Tautschnig wrote: + [ ! -f /usr/info/dir ] + [ ! -f /usr/share/info/dir ] + install_from_default /usr/share/base-files/info.dir /usr/share/info/dir + [ ! -f /usr/share/info/dir ] + cp -p /usr/share/base-files/info.dir /usr/share/info/dir + chmod 644 /usr/share/info/dir + chown root:root /usr/share/info/dir chown: invalid user: 'root:root'
Thanks a lot for this. I was mistaken/confused. The recently added three lines at the end of base-files postinst may not be the reason for debootstrap fail. I've moved them anyway to a better place. Now we have this "chown root:root /usr/share/info/dir" that fails. If this is the *only* place where it fails, this could be ommited because postinst is executed by root and the chown is not really required. > > Regarding previous point, it should be noted that base-files postinst > > has a lot of chown calls. I would like to know how it is possible that > > only the recently added is the one that fails and not the others > > (if that's really the case). > > I suppose none of the others are being executed as all of them are guarded by > some combination of checks? I refer specifically to the big "if" block starting if [ "$1" = "configure" ] && [ "$2" = "" ]; then There are a lot of "install_directory" calls there. If any of them fails because of the root user does not exist yet, all of them will fail. But those lines have been there since a long time, so after base-files_7.9 where I moved the lines that create /mnt on upgrades, I don't really see what recent change in base-files could be the reason (or better, the trigger) for debootstrap failure. It must be something else. > As you please. I was just hoping to find potential options other > than "revert the change in base-files." I'm still open for options for the benefit of wheezy users not using backports. But I need to have a better view of why it's failing when it was not failing before, if that's really the case. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
