[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: