> Russ: Policy basically already does that, doesn't it? It's not
> normative (maybe it should be), but that's how I always read 10.9.1:
I didn't think it forbade it. If that was the intent, I think it should
be clearer.
> Russ: I'd personally be happy to strengthen that to say that you
> should
On Wed, 03 Feb 2010, Brandon wrote:
> I bet there will be several. On my system currently, xcdroast and
I think this is a holdover from when xcdroast asked a debconf
question; it's probably a bug that that code is still there... file
it!
> xsendmail use stat overrides unnecessarily.
I don't know
also sprach martin f krafft [2010.02.04.1336 +1300]:
> In short, I am in favour of forbidding use of dpkg-statoverride by
> package maintainers, unless I missed something in the above.
Further information from IRC:
< madduck> sgran: feel free to slam me down on my latest
reply to #568313 wrt t
On Thu, 04 Feb 2010, martin f krafft wrote:
> I can perfectly understand admins wanting to override package
> defaults, but not why the package maintainer needs to use
> dpkg-statoverride.
You need to use dpkg-statoverride when you are using a dynamic uid/gid
and files that you ship need to be set
martin f krafft writes:
> I tend to agree. With that in mind, though, why would one ever want/need
> to chmod/chown files under control by dpkg (which are the only ones for
> which dpkg-statoverride applies to) *from postinst*? I can perfectly
> understand admins wanting to override package defa
also sprach Russ Allbery [2010.02.04.1245 +1300]:
> I suppose it's a question of what the best defaults are, but I prefer the
> behavior of assuming the ownership and permissions shipped in the package
> are correct and the installed files should be modified to match. The case
> where I want to p
Brandon writes:
> I still think that dpkg-statoverride should be forbidden in the case
> where the uid and gid are static.
Policy basically already does that, doesn't it? It's not normative (maybe
it should be), but that's how I always read 10.9.1:
Given the above, dpkg-statoverride is ess
retitle 568313 Suggestion: forbid the use of dpkg-statoverride when uid and gid
are static
thanks
You're right Russ. In that scenario, there would a be a short period of
time where the permissions would not be set correctly.
I still think that dpkg-statoverride should be forbidden in the case
wh
Processing commands for cont...@bugs.debian.org:
> retitle 568313 Suggestion: forbid the use of dpkg-statoverride when uid and
> gid are static
Bug #568313 [debian-policy] Suggestion: forbid the use of dpkg-statoverride in
postinst scripts, except for --list
Changed Bug title to 'Suggestion: for
This one time, at band camp, Brandon said:
> As for setting permissions for files with dynamic ids, debian policy
> says that dpkg-statoverride is necessary. This is not true, or at least
> misleading.
How do you expect packages to maintain correct ownerships and
permissions on files owned by dyna
Brandon writes:
>> If you set the permissions with chown, aren't they overwritten every
>> time the package is upgraded and then have to be reset again
> No. You have to check for overrides first, and only chown/chmod if there
> aren't any in place. You have to do this regardless of which metho
On Thu, 4 Feb 2010 12:36:34 +1300
martin f krafft wrote:
> also sprach Russ Allbery [2010.02.04.1222 +1300]:
> > If you set the permissions with chown, aren't they overwritten
> > every time the package is upgraded and then have to be reset again,
> > leaving windows on every upgrade when they h
martin f krafft writes:
> also sprach Russ Allbery [2010.02.04.1222 +1300]:
>> If you set the permissions with chown, aren't they overwritten every
>> time the package is upgraded and then have to be reset again, leaving
>> windows on every upgrade when they have the wrong permissions?
> Maybe
> leaving windows on every upgrade when they have the wrong permissions?
Oh. I know what this means now. I was thinking of glass windows. Or
maybe MS Windows. There is no point in time where the user would have
the wrong permissions, as long as the package scripts are done
correctly.
-Brandon
s
also sprach Russ Allbery [2010.02.04.1222 +1300]:
> If you set the permissions with chown, aren't they overwritten every time
> the package is upgraded and then have to be reset again, leaving windows
> on every upgrade when they have the wrong permissions?
Maybe dpkg could be taught to preserve
> > As for setting permissions for files with dynamic ids, debian policy
> > says that dpkg-statoverride is necessary. This is not true, or at
> > least misleading. Certainly the post install script should check to
> > make sure that there isn't any override in place before setting
> > file permiss
Brandon writes:
> As for setting permissions for files with dynamic ids, debian policy
> says that dpkg-statoverride is necessary. This is not true, or at least
> misleading. Certainly the post install script should check to make sure
> that there isn't any override in place before setting file p
To give everyone an idea of how much simpler the package scripts are
that don't use dpkg-statoverride to set permissions, here is the example
from the policy document:
postinst:
for i in /usr/bin/foo /usr/sbin/bar
do
# only do something when no setting exists
if ! dpkg-stat
> > First, I suggest that Debian Policy require, or at least recommend,
> > that packages not use dpkg-statoverride to set permissions for files
> > with static uids and gids. In other words, if it is possible for the
> > maintainer to set the permissions in the package binary itself, then
> > he s
On Wed, 03 Feb 2010, Brandon wrote:
> First, I suggest that Debian Policy require, or at least recommend,
> that packages not use dpkg-statoverride to set permissions for files
> with static uids and gids. In other words, if it is possible for the
> maintainer to set the permissions in the package
Package: debian-policy
Version: 3.8.4.0
Severity: wishlist
Regarding Debian Policy 10.9.
First, I suggest that Debian Policy require, or at least recommend,
that packages not use dpkg-statoverride to set permissions for files
with static uids and gids. In other words, if it is possible for the
ma
21 matches
Mail list logo
