On Fri, 2012-05-18 at 13:49:19 +0200, Goswin von Brederlow wrote:
> Roger Leigh 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 c
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 o
Roger Leigh 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 wa
On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote:
> Roger Leigh 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
Roger Leigh 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
> m
Russ Allbery writes:
> Charles Plessy writes:
>
>> in some of my packages, I give the ownership on some directories in /var
>> to www-data without checking that the www-data group exists, but I guess
>> it is acceptable because it is globally allocated by base-passwd.
>
> Right.
>
>> Dpkg will n
]] Vincent Zweije
> No, this is about packing. Doing packing with dpkg-deb invoking bsdtar
> would either make bsdtar essential, or require that dpkg-deb switch to
> use whatever tar is available.
Why would it require more than dpkg-dev depending on bsdtar? We have
precedence for packages being
On Tue, May 15, 2012 at 01:06:54PM +0100, Ian Jackson wrote:
|| Guillem Jover writes ("Re: on the use of chmod/chown in maintainer
scripts"):
|| > On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote:
|| > > I can't see an equivalent in GNU tar. But BSD tar is ava
Guillem Jover writes ("Re: on the use of chmod/chown in maintainer scripts"):
> On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote:
> > I can't see an equivalent in GNU tar. But BSD tar is available
> > in Debian.
>
> This would imply BSD tar needs
* Russ Allbery (r...@debian.org) [120513 18:52]:
> Carsten Hey writes:
> > * Andreas Barth [2012-05-13 11:06 +0200]:
> >> and let dpkg handle all of that?
>
> > This doesn't look like a task that should be done by dpkg itself;
> > instead debhelper or dpkg-maintscript-helper could be used.
>
>
Carsten Hey writes:
> * Andreas Barth [2012-05-13 11:06 +0200]:
>> * Russ Allbery (r...@debian.org) [120512 23:06]:
>>> Usually because the UID is dynamically assigned and the user is
>>> created in the postinst, so there's no way for dpkg do do this at
>>> unpack.
>>> You would need to apply pe
On Sun, 13 May 2012, Leo "costela" Antunes wrote:
> Hi,
>
> On 12/05/12 12:23, Peter Palfrader wrote:
> > This may not be entirely trivial to solve. find | xargs constructs at best
> > mitigate this to a race. While chown does have a --no-derefence flag, this
> > does not protect us in the case
Hi,
Is there anybody familar with Solaris IPS manifests [1]?
They are terrible and unflexible, but allow describing users, permissions
etc.
I thinks post/pre/install/remove scripts are create advantage, cause
they allow do dirty things *iff* needed.
[1]
http://www.oracle.com/technetwork/server-
Hi,
On 12/05/12 12:23, Peter Palfrader wrote:
> This may not be entirely trivial to solve. find | xargs constructs at best
> mitigate this to a race. While chown does have a --no-derefence flag, this
> does not protect us in the case of hardlinks. chmod has no such flag, and
> it'd
> useful on
* Andreas Barth [2012-05-13 11:06 +0200]:
> * Russ Allbery (r...@debian.org) [120512 23:06]:
> > Charles Plessy writes:
> >
> > > Unless we expect that two different binary packages that can be
> > > co-installed will distribute the same directory under different
> > > ownership or permissions for
* Russ Allbery (r...@debian.org) [120512 23:06]:
> Charles Plessy writes:
>
> > Unless we expect that two different binary packages that can be
> > co-installed will distribute the same directory under different
> > ownership or permissions for a good reason, why not simply let dpkg
> > apply own
Charles Plessy writes:
> in some of my packages, I give the ownership on some directories in /var
> to www-data without checking that the www-data group exists, but I guess
> it is acceptable because it is globally allocated by base-passwd.
Right.
> Dpkg will not update permissions or ownership
On Sun, 2012-05-13 at 01:17:35 +0100, Roger Leigh wrote:
> On Sun, May 13, 2012 at 02:10:13AM +0200, Guillem Jover wrote:
> > This would imply BSD tar needs to be promoted to the Essential set
> > alongside GNU tar, at which point I might as well just use an
> > internal tar implementation.
>
> Wo
Le Sat, May 12, 2012 at 02:06:16PM -0700, Russ Allbery a écrit :
>
> Usually because the UID is dynamically assigned and the user is created in
> the postinst, so there's no way for dpkg do do this at unpack.
>
> You would need to apply permissions by name, not UID/GID, and you would
> need to cr
On Sun, May 13, 2012 at 02:10:13AM +0200, Guillem Jover wrote:
> On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote:
> > On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote:
> > > One option would be to make dpkg-deb use an internal tar implementation,
> > > and add a file describing
On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote:
> On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote:
> > One option would be to make dpkg-deb use an internal tar implementation,
> > and add a file describing the attributes of the to be packaged files.
> > That might make needin
On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote:
> On Sat, 2012-05-12 at 12:28:27 +0100, Roger Leigh wrote:
> > On Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader wrote:
> > With the above approach, the only hard question is how to set the
> > ownership during the package build
Charles Plessy writes:
> Unless we expect that two different binary packages that can be
> co-installed will distribute the same directory under different
> ownership or permissions for a good reason, why not simply let dpkg
> apply ownership and permissions found in data.tar.{gz|bz2|xz},
Usuall
On Sat, 2012-05-12 at 12:28:27 +0100, Roger Leigh wrote:
> On Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader wrote:
> > A lot of daemon packages in Debian nowadays create their own user and groups
> > during installation. Usually this also implies that a couple of files and
> > directories
On 2012-05-12 13:10 +0200, Charles Plessy wrote:
> I was always wondering:
>
> Unless we expect that two different binary packages that can be co-installed
> will distribute the same directory under different ownership or permissions
> for
> a good reason, why not simply let dpkg apply ownership
On Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader wrote:
> A lot of daemon packages in Debian nowadays create their own user and groups
> during installation. Usually this also implies that a couple of files and
> directories are created, and then chmodded and chowned to some appropriate
>
Le Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader a écrit :
>
> In some cases[1], this chmodding and chowning is done on each package upgrade,
> either because things changed over time and just doing it unconditionally
> seems
> like the easiest thing, or just because hey, it doesn't hurt
Hey all,
A lot of daemon packages in Debian nowadays create their own user and groups
during installation. Usually this also implies that a couple of files and
directories are created, and then chmodded and chowned to some appropriate
value for the service in question.
In some cases[1], this chm
28 matches
Mail list logo
