Roger Leigh <rleigh@codelibre.net> writes:

> With the above approach, the only hard question is how to set the
> ownership during the package build. fakeroot handles this just fine,
> but it does require the user/group to be present on the build
> system, which will not always be the case. Is there an alternative
> means to set/override the ownership during packing of a tarfile?

Shouldn't be to hard to make fakeroot also create fake users and groups
specified in debian/passwd and debian/group (or similar).

That just leaves the question of wether dpkg uses uid/gid or symbolic
names when unpacking debs.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 874nrgqp1l.fsf@frosties.localnet">http://lists.debian.org/874nrgqp1l.fsf@frosties.localnet

On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote:
> Roger Leigh <rleigh@codelibre.net> writes:
>
> > With the above approach, the only hard question is how to set the
> > ownership during the package build. fakeroot handles this just fine,
> > but it does require the user/group to be present on the build
> > system, which will not always be the case. Is there an alternative
> > means to set/override the ownership during packing of a tarfile?
>
> Shouldn't be to hard to make fakeroot also create fake users and groups
> specified in debian/passwd and debian/group (or similar).

fakeroot is the wrong level to do this. Think about how you are
dependent upon the NSS databases and you need a valid db for
the chown/chmod commands to work. Coupled with the fact that
fakeroot is not required for building, I don't think this is a
good plan. A wrapper around or replacement for chown/chmod is a
possibility; this could store the changes in a file, rather than
change the on-disc perms, ready for dpkg-deb to use.

> That just leaves the question of wether dpkg uses uid/gid or symbolic
> names when unpacking debs.

I think this one is clear: it must be symbolic since the uids/gids
aren't static. Unless you want to provide a package-specific
mapping in the control data, and I can't see that gains much, since
it makes unpacking unnecessarily complex. If it's symbolic, you
simply just extract it.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120516130809.GB22466@codelibre.net">http://lists.debian.org/20120516130809.GB22466@codelibre.net

Roger Leigh <rleigh@codelibre.net> writes:

> On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote:
>> That just leaves the question of wether dpkg uses uid/gid or symbolic
>> names when unpacking debs.
>
> I think this one is clear: it must be symbolic since the uids/gids
> aren't static. Unless you want to provide a package-specific
> mapping in the control data, and I can't see that gains much, since
> it makes unpacking unnecessarily complex. If it's symbolic, you
> simply just extract it.

Full ACK on symbolic. The question is what dpkg currently does. Do we
need to fix dpkg or is dpkg already ready for this?

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 871umhlneo.fsf@frosties.localnet">http://lists.debian.org/871umhlneo.fsf@frosties.localnet

Hi Peter,

Thanks for bringing up this issue again. Admittedly, there hasn't been much
progress since it was discussed last year.

Hopefully, the discussion has focused on a solution to completely avoid the
problem during upgrades.
For the general issue, the only progress I made was in the form of #608623,
but I haven't spent any time trying to implement lchmod in the kernel.

Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: jp6rda$8st$1@dough.gmane.org">http://lists.debian.org/jp6rda$8st$1@dough.gmane.org

On Fri, 2012-05-18 at 13:49:19 +0200, Goswin von Brederlow wrote:
> Roger Leigh <rleigh@codelibre.net> writes:
> > On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote:
> >> That just leaves the question of wether dpkg uses uid/gid or symbolic
> >> names when unpacking debs.
> >
> > I think this one is clear: it must be symbolic since the uids/gids
> > aren't static. Unless you want to provide a package-specific
> > mapping in the control data, and I can't see that gains much, since
> > it makes unpacking unnecessarily complex. If it's symbolic, you
> > simply just extract it.
>
> Full ACK on symbolic. The question is what dpkg currently does. Do we
> need to fix dpkg or is dpkg already ready for this?

Because deb packages use tar as the container, this restricts dpkg to
what that supports. Non-ancient formats (i.e. non-V7 tar formats) store
numeric and symbolic names for the file user and group. dpkg has always
tried to use the symbolic name if it's been known to the system, and
has used the numeric value as a fallback otherwise. Relying exclusively
on numeric user/group would not be sane. So dpkg has always “been ready�
for this.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120525010915.GA16519@gaara.hadrons.org">http://lists.debian.org/20120525010915.GA16519@gaara.hadrons.org