transition from suidmanager to dpkg-statoverride
Dpkg 1.8.x in unstable supports a new dpkg-statoverride mechanism that
allows the permissions and owners of any file to be overridden, in a
manner that is persistent accross upgrades. We are now ready to begin
the transition from suidmanager to the new mechanism.
Today suidregister 0.50 was installed into unstable. When you upgrade to
this version of suidregister, your /etc/suid.conf file will be imported
into dpkg-statoverride, and removed.
After that, if you install any packages that use suidregister, they
should notice that the suidmanager command does not exist anymore, and
fall back to not using it. We've given a great deal of thought to the
transition, and it should be painless and trouble-free.
Although packages that used to use suidmanager will keep working more or
less all right, they should be updated as soon as possible to no longer
call suidregister in their postinst and postrm scripts. Instead, packages
now can just include suid/sgid binaries in the .deb, and dpkg-statoverride
will automatically work.
There is one wrinkle: If your package previously used suidmanager, and
you convert it to not, you should make it Conflicts: suidmanager (<< 0.50).
(The details of why are a little messy; see earlier discussion on
debian-devel.)
For debhelper users: Debhelper 2.2.12, which should be installed tomorrow
(in Incoming now) has been modified to use the new system (just follow the
warning/error messages the new version of dh_suidregister displays.)
Once again, I urge everyone who has a package that uses suidmanager to
change it so it does not, and add the necessary versioned conflicts.
Thank you.
--
see shy jo
Reply to: