Re: dpkg-statoverride vs. suidmanager
Wichert Akkerman wrote:
> > * Make a new suidmanager package that predepends on the new line of dpkg
> > packages and, in its preinst, converts everything to use statoverride.
> > * Dpkg doesn't need any support for suidmanager conversion stuff at all.
> > * Any package that once used suidmanager and is updated to no longer use
> > it, needs to conflict with old version of suidmanager, since installing
> > it on an older system with the old suidmanager will cause it to trample
> > over the permissions the user has set.
> This still leaves us with two problems:
> 1. there is no 100% correct way to decide if something is an override
> or not
They're flagged local or so arn't they?
> 2. the statoverride db will be cluttered with overrides that are only
> there because the old package does not contain suid binaries when the
> default is suid
Not sure I follow. If you just import the 'local' entries, this should
not be the case.
> > There's still the problem of how I get packages that call
> > dh_suidregister to have a versioned conflicts, but I guess that's my
> > problem, not your problem. :-)
> Automatic adding of a versioned conflict.. I'm suddenly extra glad none
> of my packages use debhelper.
Yeah, that's the ticket. I'll be renaming it to debstd too..
see shy jo, who wonders if wiggy was confusing the two ...