Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)
Simon McVittie writes ("Re: individual packages moving binaries from /bin to /usr/bin (was: Re: usrmerge -- plan B?)"):
> I'm not sure yet what the best plan for merged /usr is. I would definitely
> like to make sure it's at least possible to continue to use merged
> /usr for special-purpose systems (particularly containers and embedded
> systems), even if it comes with major caveats like "can't reliably build
> Debian packages suitable for other systems";
To be very clear: I have no problem with this at all.
> I personally think everyone
> should be using sbuild or equivalent, either on a buildd or locally,
> to build "release-quality" packages suitable for distribution to other
> systems *anyway*, but I know that view isn't necessarily universal.
"Suitable for distribution to other systems" is rather a moveable
feast. I absolutely agree if you mean formal publication as part of
some kind of release.
But I'm sure all of us have on occasion done ad-hoc builds and then
copied the .deb somewhere else to install it. Indeed my own
experience is that during development I rarely use a chroot. I think
someone should be able to build some software on their own computer
and give the binaries to a friend, without having to set up a chroot.
I also think that setting up a chroot should be made easier and that
more people should use chroots. I don't think these views conflict.
> For at least special-purpose systems, merged /usr seems to work fine with
> stretch, and I was able to get it working in an Ubuntu 12.04 derivative
> by backporting a single-digit number of changes, so that particular genie
> has been out of the bottle for quite some time anyway.
Would it be helpful to make some of this explicit in Debian policy ?
IMO binary packages shipped by Debian should certainly support
installation on both merged-usr and separate-usr systems.
And I wouldn't object to a rule that our source packages must build
`correctly' on both such systems, subject to the caveat that the
results from a merged-usr build are not of general applicability and
should be used only in a closed environment where all the target
systems are also merged-usr.
Does that make sense ?
Ian Jackson <email@example.com> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.