Re: dpkg-statoverride vs. suidmanager
I just read this whole bloody thread again for the last time. Here is
what we decided to do:
> > * New suidmanager depends on new dpkg, and on upgrade, imports all
> > local suid.conf overrides into statoverride.
> > * New packages do not need to register with suidregister, so they will
> > contain actual suid executables.
> * New packages conflict: with old suidmanager
However, dpkg 1.8 implements dpkg-statoverride --import. We decided not
to go that route, so why?
What we need is to get a new suidmanager uploaded that depends on
dpkg >= 1.8 and imports suid.conf.
see shy jo