Re: FHS - transition
Manoj Srivastava writes ("Re: FHS - transition") [1]:
> "Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
> > My scheme:
...
> > * [list of bullet points snipped]
> * Needs a flag day for the transition
To my mind, a flag day is a point in time when the entire universe
must change simultaneously, or at least across which mechanisms do not
interoperate. I feel that a flag day necessarily occurs at the same
time for everyone.
In my proposal, there is no such day. Every system can independently
choose when to switch to the new layout, if at all.
Can you rephrase your objection ? Or you could explain what you mean
by `flag day' and why you think they (as you define them) are a bad
thing, though I think that'll lead to an unhelpful sidetrack.
...
> * Does not need a script for transition;
I don't see this as a big advantage. The relevant script is not that
difficult. I'll even volunteer to write it.
> transition happens on
> a package by package basis, not a siter basis.
I don't see this as an advantage. It's certainly the key difference
between your proposal and mine.
> * Backward compatibility is builtin, except for a handful of
> packages, which are supposed to be upgraded *first*, a
> release or so before the move
`supposed to be'. I think that my scheme, which copes better with
version skew, is superior in this respect.
> * Move to /usr/share is held off for a bit, but when it
> happens, it can be transparently gradual.
Why is moving an individual system to /usr/share gradually a good
thing ? Surely if you were running your own system by hand you'd use
a symlink, and then move the files all at once ?
For example, consider the case where /usr/share _is_ a different
filesystem. In your proposal the data volume moves gradually from one
partition to another, which is a distinct disadvantage. With a
separate copying script it could notice the directories are on a
different filesystem and point this out when offering to move them,
and it could even check that there will be room.
...
> > I think the only other way to get the required ease of partial upgrade
> > is to _refuse_ to allow _any_ new-layout packages to be released until
> > at least one or two full releases after _all_ browser packages have
> > been changed. (And how do we check that we didn't miss one?)
>
> Correct. And we can can get the most common packages off the
> top of our heads (or looking at /var/lib/dpkg/available). Do you
> trust the developers so little? If we wait for a release or so before
> beginning our gentle transition, surely enough time is given for most
> developers to massage the packages that we missed? If not, we can
> always file bugs.
How many libc5 packages are still in our distribution (or libc4 ones,
for that matter) ?
I think that the most robust and best distribution will be obtained if
we don't put the work of many different developers on each others'
critical paths.
...
> We can create a test changes document package that put
> documentation in /usr/share/man, /usr/share/doc. and
> /usre/share/info, and see f the manual browsers can see that
> documentation.
Yes, we could.
> > With my proposal we can start making the move straight away.
>
> I think we can wait long enough to do it right, with no flag
> days at all.
Your key objection seems to be this `flag day' concept, which differs
from mine. Again, could you explain it more fully ?
If it were a question of doing it right or doing it soon I would agree
with you that we should do it right. However, I don't see it that
way.
...
> I do not want a system wide global flag day script. dpkg is
> designed to upgrade packages, even when some file locations
> change. When I moved files from /usr/doc/mailagent/examples/new to
> /usr/doc/mailagent/examples/sbin, I did not create a script. dpkg
> handled that flawlessly.
>
> I fail to see a difference.
The difference is that the change we're contemplating has system-wide
significance, unlike your example. It has this significance both for
packages that supply files and ones that read them.
dpkg's behaviour with links-to-directories is carefully designed to
work properly during transitional arrangements like the one I'm
proposing to use here (and other nonstandard arrangements eg where
local admins use links to manage disk space).
> > Surely the scheme I proposed, with a transitional symlink, and then
> > moving everything at some future date, is just what a sysadmin would
> > do if they were maintaining the system by hand ?
>
> Yep. Sysadmins like flag dasys, gives them a sense of pawer ;-)
Eh ?
I think that if you agree that doing something a particular way would
be the way you'd do it if you were running the system yourself without
a distribution, then you have to explain why what's best for an
individual system isn't best on millions of individual systems.
Ian.
[1] Apologies for the poor formatting of Manoj's message in my quoted
text, which has resulted from my undoing of the awful `SuperCite'
quoting style, which even the author of SuperCite now admits to have
been a bad idea.
Reply to: