Hello Marco d'Itri. On Thu, Dec 31, 2015 at 01:51:45AM +0100, Marco d'Itri wrote: > We have a reasonably tested usrmerge package which can be used to [...] > I welcome your comments, but if you have any questions then please read > the FAQ first: > https://wiki.debian.org/UsrMerge > https://anonscm.debian.org/cgit/users/md/usrmerge.git/plain/debian/README.Debian > > If you want to help then please have a look at the open bugs linked on > wiki.d.o about lintian and policy work.
Thanks for your work on this! (even though I'd personally would be happy if this went one step further with "TheOneAndOnlyTrueBin" from Arch Linux fame so I'd never have to waste time being involved in another discussion about where the right place to put an executable is. As I learned at debconf, "technical solution to social issues"...) I just found some time to read through the sources of usrmerge and ended up with a couple of comments that I'm not sure is worth implementing but mentioning them anyway in case anyone is interested... First, it would be nice to have a preinst check if the system has any running services that uses ProtectSystem and offer a choice to stop (and restart) them in case having them running is really a problem... (Similar to how glibc upgrades (used to?) offer restarting of services.) While codesearch tells me these seem to be pretty uncommon in the archive right now, AFAIK it's pretty much a recommended setting for services that works with it enabled and with the ever growing number of services in the archive I can only guess that also enabling this setting will become more common.... An easier way for the users to deal with this might be worth some developer time. Second, as you already noted in your TODO I think it's probably a good idea to turn the initramfs preinst check into a debconf prompt. And to answer your followup question in TODO, no I do not think you should always prompt on /usr on separate fs. Don't bother the user unless needed. This way the messages should properly show up in all package management frontends and can also be translated. Last but not least thanks for so clearly documenting the tradeoffs you have had to make and mark the XXX spot where to look closer. I don't feel like I'm in a position to give any recommendations on which side of the remaining tradeoffs to lean towards. (I'm also very curious that noone from the critical crowd has picked up on your documented issues, but OTOH it seems many didn't even read the FAQ....) Regards, Andreas Henriksson
