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).
This is explicitly NOT WHAT WE HAVE PROMISED OUR USERS.
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
programs.
...
> 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
organised.
> 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
it.
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.
Ian.
Reply to: