Re: FHS - transition
Hi,
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
Ian> Biased summary:
Biased is right.
Ian> My scheme:
Ian> * keep the user's filesystem consistently laid out during transition.
Ian> * allows the transition to be controlled explicitly by a single script.
Ian> * allows us to start moving packages to /usr/share nearly straight
Ian> away.
Ian> * can preserve backward compatibility indefinitely
Ian> (ie old packages on new systems)
Ian> * will require upgrade of only one core package (which does not
Ian> itself have many dependencies) for forward compatibility (new
Ian> packages on old systems)
* Needs a flag day for the transition
* Has a requirement to have backwards compatibility
Your opponents scheme (fix info browsers first, and then allow
both locations for info, man, doc, et al)
* Seamlessly allow upgrades, partial upgrades, and a transition
period with no flag days ever.
* Does not need a script for transition; transition happens on
a package by package basis, not a siter basis.
* Backward compatibility is builtin, except for a handful of
packages, which are supposed to be upgraded *first*, a
release or so before the move
* Move to /usr/share is held off for a bit, but when it
happens, it can be transparently gradual.
Ian> I think the only other way to get the required ease of partial upgrade
Ian> is to _refuse_ to allow _any_ new-layout packages to be released until
Ian> at least one or two full releases after _all_ browser packages have
Ian> 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.
However, I think we can get 90% of the packages that require
changing a priori.
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.
Ian> 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.
Ian> I think perhaps you just want to push the problem out of some
Ian> installation script (eg base-files's postinst in my scenario) into
Ian> dpkg. The files will actually have to move eventually, it's just a
Ian> question of whether dpkg does it one package at a time, or a
Ian> well-controlled special-purpose script does it all at once per system.
Ian> I don't think dpkg is the right tool for this.
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.
Ian> Surely the scheme I proposed, with a transitional symlink, and then
Ian> moving everything at some future date, is just what a sysadmin would
Ian> do if they were maintaining the system by hand ?
Yep. Sysadmins like flag dasys, gives them a sense of pawer ;-)
manoj
--
There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies and the
other is to make it so complicated that there are no obvious
deficiencies. C.A.R. Hoare
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: