Re: dpkg-statoverride vs. suidmanager

[Joey Hess <joeyh@debian.org>]

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 ...