Re: FHS - transition
I wrote:
>> 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:
Ian Jackson wrote:
>You must be kidding.
Why must I be? I was quite serious. I still am.
Of course, it probably didn't help that my argument was rather garbled
before. I hadn't thought things out before I started writing my email,
so some of the things I wrote were quite irrelevant. I'm not sure why I
didn't remember to delete them before sending my message, but I'll try to
be more clear this time. I know my ideas are not finished or complete,
and I'm hoping to get some reasonable criticism here (and "you must be
kidding" doesn't really help).
- - -
My main problems with your proposal are:
1) It involves predependencies. These are problematic on many old
versions of many of the dselect methods. If we can get away without
predependencies, we should.
2) It involves writing a script especially for this one transition.
We'll have to debug that script thoroughly to ensure we don't clobber
many systems; then, we may not be able to easily reuse that work
whenever the next transition happens.
3) It involves deliberately invalidating dpkg's database. It's fine
that dpkg is capable of following symlinks (but then, isn't every unix
program capable of following symlinks?), but dpkg's database records
the location the file would have occupied, had the symlink not been
there, rather than its real, physical location. This is also fine
(usually) since, on the whole, these symlinks are placed there by
the sysadmin, and he will know to move files around appropriately
if he changes the symlink.
However, if the sysadmin sees a symlink placed there by our
distribution, he's more likely to think that it's just for
compatibility, and so might change it without shuffling files
around correctly. In this case, dpkg is going to lose track of
files installed via that symlink.
4) It requires the sysadmin to do some work to bring their system
up-to-date, other than what dpkg, dselect, apt and friends can do
automatically. You've (successfully IMO) argued that the sysadmin
-should- be able to control when the bulk of the files are moved from
/usr to /usr/share. This requires some kind of "do the move" script.
However, I think we should also try to offer the option of having
the move done without the sysadmin needing to find, learn about and
run such a script. (Of course, some sysadmins could just ignore the
script and live with things in the old locations forever. However,
that requires that we never try to re-use the old locations.)
- - -
Due to point 2, we should factor out the stuff which isn't specific
to -this- transition. We could either turn it into a new tool,
dpkg-bulkmove, or add it as an improvement to an existing tool.
(I argued (or tried to) that adding it to dpkg-divert would be logical,
because that tool already has a very similar job; it moves files,
and it tells dpkg that it's done it (which would also solve point 3).
Effectively, this amounts to extending dpkg-divert to be able to move
any and all files with a given prefix; diverting entire directory trees.)
We can also fix point 1; if a few files can be installed into /usr/share,
but then be moved back when base-files is configured, we now don't
have to use pre-depends to ensure that base-files gets to do its thing
before -any- file gets installed in the new location, because we are
able to move back any files already installed into the new locations.
(This requires some integration with dpkg.) (Incidentally, Ian, what were
you planning for base-files to do if /usr/share/info already existed,
when it came to symlink it to /usr/info? Would it move the existing
files across by itself, or just bomb out and require the sysadmin to
clean out /usr/share/info before allowing itself to be installed?)
Re point 4: People don't want to learn anything new; force them to learn
a new command just for one special-purpose use, and they'll hate you.
Give them a new general-purpose tool (particularly one with a useful
"killer feature", see below) and they might take the trouble to learn it,
since it might be useful in the future.
I believe my proposal does almost exactly what you suggested should
be done (divert files out of /usr/share, then moves them back when
the sysadmin says so), but in a different manner, which addresses the
points above.
- - -
I've taken a proper look at dpkg-divert now, and I see that it's not
really built for anything like this; for example, it can't move files
across filesystems, and the format of /var/lib/dpkg/diversions probably
isn't expressive enough for the task. We probably need to build a new
tool, perhaps "dpkg-bulkmove", which interfaces with dpkg in a similar way
to the way dpkg-divert does. If we did it right, dpkg-bulkmove would be
general enough to be able to handle other transitions than the FSSTND ->
FHS one.
The scheme would then be something like this:
- Version X of the dpkg package contains the dpkg-bulkmove tool.
- Version Y of base-files depends on dpkg ( >= X ).
- All packages (for a release or two) using the new layout depend on
base-files ( >= Y ).
- When base-files (Y) is configured, it executes
dpkg-bulkmove --install --from /usr/share/info --to /usr/info
which results in any files already installed in /usr/share/info being
moved to /usr/info, and /usr/share/info being removed (if empty).
Any further files installed by dpkg in /usr/share/info then get
diverted to /usr/info. (Not by a symlink, but by a method similar
to dpkg-divert's.)
- To perform the local "flag-day", moving all the files across to
/usr/share, (once all the browsers on the machine were updated),
the sysadmin would do
dpkg-bulkmove --uninstall --from /usr/share/info --to /usr/info
(or perhaps would execute a simple script which would do this for him).
If he wanted to, he could also do
dpkg-bulkmove --install --from /usr/info --to /usr/share/info
- - -
(I'm also thinking that this dpkg-bulkmove idea could provide a way to
implement another mechanism that has been on dpkg's wishlist for a very
long time...
dpkg-bulkmove --install --delete /usr/doc
dpkg-bulkmove --uninstall --delete /usr/doc
or
dpkg-bulkmove --install --compress /usr/doc
dpkg-bulkmove --uninstall --compress /usr/doc
These commands could be used to remove/compress everything installed under
/usr/doc. (Of course, that second command would not be able to magically
restore the deleted files; it would either have to wait for packages
to be reinstalled, or at "--install" time, copies of the removed files
could optionally be squirreled away for a later reinstall.) (This could
be the "killer feature" I mentioned which persuades sysadmins that the
tool is worth learning about. If regexps were used instead of prefixes,
this could even allow the selective compression of HTML documentation.)
- - -
(Incidentally, WRT the "flag-day" disagreement between Ian and Manoj:
I think you each have a different idea of -who- a flag-day applies to.
Ian's idea of a flag-day seems to be for the distribution, Manoj's for
the individual Debian system. Ian's proposal requires a flag-day on
each system, one where the sysadmin has to invoke a big all-or-nothing
transition; the gradual-move proposal requires a flag-day for the
distribution, a point where we start assuming that all the browsers
are updated on all Debian systems.
In fact, I'm still not sure that a gradual-move type scheme can't be
offered as an option -- some systems don't have /usr/share on a separate
partition, and some will have a large partition already, in anticipation
of this move, and thus won't need (or don't want) a local flag-day.)
- - -
I know I'm producing a -lot- of hot air here, and no code. I don't know
dpkg's internals at the moment, but I'm willing to try learning it and
help implement this thing if anyone thinks it's a good idea.
Finally, Ian, would you please critique the actual proposal this time,
rather than replying to the tangential stuff and dismissing the main
proposal with a "you must be joking"? (I admit I didn't make it too
easy, last time, to tell what was tangential and what wasn't. I hope
I've done better this time.)
Thank you,
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
Reply to: