On Fri, 2012-05-18 at 13:49:19 +0200, Goswin von Brederlow wrote:
Roger Leigh rle...@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
Roger Leigh rle...@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.
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
Russ Allbery r...@debian.org writes:
Charles Plessy ple...@debian.org 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.
Roger Leigh rle...@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
On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote:
Roger Leigh rle...@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
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 to be promoted to the Essential set
alongside GNU
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 available
||in Debian
]] 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
* Russ Allbery (r...@debian.org) [120512 23:06]:
Charles Plessy ple...@debian.org 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
* Andreas Barth [2012-05-13 11:06 +0200]:
* Russ Allbery (r...@debian.org) [120512 23:06]:
Charles Plessy ple...@debian.org writes:
Unless we expect that two different binary packages that can be
co-installed will distribute the same directory under different
ownership or permissions
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 only
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]
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 of
Carsten Hey cars...@debian.org 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
* Russ Allbery (r...@debian.org) [120513 18:52]:
Carsten Hey cars...@debian.org 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
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
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,
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
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 and
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 are
Charles Plessy ple...@debian.org 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
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.
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 needing root
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 the
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 create
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.
Won't this
Charles Plessy ple...@debian.org 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
28 matches
Mail list logo
