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

Re: FHS - transition

Charles Briscoe-Smith writes ("Re: FHS - transition"):
> Ian Jackson wrote:
> > * will require upgrade of many packages for forward compatibility.
> How many browsers are in use on each machine?  How many machines are
> upgraded one package at a time?  (I suspect most are upgraded lock, stock
> and barrel to a complete new release; I think we've told our users in the
> past that this is the way to be sure everything will work at its best).


For years, we have promised them INCREMENTAL UPGRADEABILITY.  We broke
that promise in 2.0, and I hope we never break it again.

It is IMO _essential_ that a user can take a single package out of
the new release without having to upgrade a dozen large and unrelated

> Why is it a mess to have files in two places?  Why does this matter?

Because humans find it easier to find things if they're well

> I don't think there will be any need to use scripts to clean up; when
> all packages use /usr/share/{man,info}, /usr/{man,info} should be empty.
> When base-files no longer includes them, dpkg will remove them.

On many systems this will never become the case, because many `old'
systems (with a long history since initial installation) have obsolete
packages installed.

> They might expect to have to upgrade man/info browsers in order to have
> them use FHS-compliant search paths.  If they don't want to upgrade,
> we can tell them how to edit the appropriate configuration files, or set
> the appropriate environment variables.  (Or upgrade dpkg and base-files,
> if using the scheme below.)

But the user probably doesn't care about `FHS-compliant search paths'.
The user probably just wanted to upgrade their version of foowibble
because they needed such-and-such a new feature, and now suddenly
their previously-working `man' program doesn't find the manpages for

Alternatively, we add dependencies, and this user has to upgrade man,
info, all four flavour of emacs, dwww (which changes rapidly)
etc. etc.

> I can't believe that it isn't possible -- or easy -- to tell an existing
> emacs to look for info files in /usr/share/info.  I really can't.

So now you want to have the foowibble package edit Emacs's
configuration ?  Or how do you propose that this is done ?

> Another point about your scheme is that /usr/info becomes useless.
> With your scheme, we can never use /usr/info for anything else, because
> there's no way of separating /usr/info from /usr/share/info once that
> first symlink has been put in place.  This might even matter sometime.
> For example, /usr/doc might someday be used to contain documentation
> which should be different on different architectures.  (I don't (yet)
> see why that would be useful, but who knows what will happen?)

Nonsense; that link can be removed when all packages that put files in
/usr/doc (rather than /usr/share/doc) have been removed from the
relevant system.

> A better way of handling this transition might be dpkg-divert.
> (I'm not _au fait_ with dpkg-divert's details, so I'm not sure how
> much it would need to be improved before it could be used like this.)
> Assuming dpkg-divert is (modified to be) capable of diverting whole
> directory trees, the transition could go like this:

You must be kidding.


Reply to: