[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GNU/kFreeBSD packages in the Debian archive



Hi!

On Mon, 2009-06-08 at 14:21:09 +0200, Aurelien Jarno wrote:
> As a consequence, on GNU/Linux the temporary directory has lost the
> setgid bit, and is still uid=buildd, gid=sbuild. Files are unpacked with
> uid=buildd and gid=buildd, given that the temporary directory has lost
> the setgid bit.
> 
> On GNU/kFreeBSD, the temporary directory has also lost the setgid bit,
> and is also uid=buildd, gid=sbuild. Files are unpacked with uid=buildd
> and gid=sbuild as the gid is determined by the parent directory.
> 
> Some coreutils tests fail if the files are not unpack with gid being the
> primary group of the user. They are skipped if the directory is setgid,
> but the kFreeBSD case is not taken into account.
> 
> I'll temporary change /buildd to gid=buildd on the buildds, but it looks
> like we need a fix at some point. coreutils should probably be fixed,
> but skipping the tests is probably not a good idea either. I wonder if
> we should change dpkg to also force uid and gid of the temporary
> directory while unpacking. I suspect that other packages than coreutils
> might be affected. Guillem, as a dpkg maintainer, do you have an opinion
> on that?

The source should be able to build w/o the Debian packaging from an
upstream PoV anyway. The current coreutils behaviour is not really
deterministic as it depends on the system the source has been unpacked
to, the user that unpacked it (f.ex root preserves tar users by
default), and the file system options (native, mount, setgid, etc).

Given this, I'd say that if coreutils needs a specific owner in files
to be able to do some checks, then it should arrange for itself to set
them before the checks. And that the current undefined dpkg-source
behaviour should be fine as it is. This seems the most portable option
to me.

regards,
guillem


Reply to: