Re: Merging / and /usr (was: jessie release goals)
On Tue, May 07, 2013 at 04:56:04PM +0100, Roger Leigh wrote:
> On Tue, May 07, 2013 at 05:35:11PM +0200, Marco d'Itri wrote:
> > On May 07, ?????????? ?????????? <pashev.igor@gmail.com> wrote:
> >
> > > What about merging / and /usr ?
> > An ambitious plan.
> > I strongly support the "everything in /usr" scheme, but let's first
> > consolidate support for "standalone /usr must be mounted by the
> > initramfs".
>
> I'm working on this at the present (I'm re-doing the proof of concept
> patches I made a few months back, to clean it all up and make it work
> in a wider number of cases). I hope to have something by the end of
> the week, time permitting.
>
> That said, I'm not in support of moving things to /usr; it's completely
> backward. Once we have / and /usr mounted in the initramfs, then we
> can work on deduplicating shared paths on / and /usr. This will give
> us the option of migrating either way in the future (if ever). If we
> do this, I'd prefer to make /usr a symlink to / on new installs, while
> retaining full backward compatibility for existing users, and requiring
> zero packaging changes. But the other way would also be possible--it
> would just be a matter of d-i setting up the links. But none of this is
> the primary reason for doing this initially.
>
>
> Regards,
> Roger
If you make /usr a symlink to / then there will be to distinct paths
to each file and that will confuse dpkg.
The first problem that comes to mind is package A containing /bin/foo
and package B containing /usr/bin/foo. Dpkg will happily install both
without noticing the file overwrite conflict.
Or package A 1.0 contains /bin/foo and package A 1.1 contains
/usr/bin/foo. IIrc then dpkg will unpack A 1.1 (overwrite /bin/foo
with /usr/bin/foo) and then remove /bin/foo. Leaving you without
/usr/bin/foo.
MfG
Goswin
Reply to: