Re: support for merged /usr in Debian
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
Reply to: