Re: FHS - transition
Hi,
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:
Ian> To my mind, a flag day is a point in time when the entire universe
Ian> must change simultaneously, or at least across which mechanisms do not
Ian> interoperate. I feel that a flag day necessarily occurs at the same
Ian> time for everyone.
For me, a flag day is when on my machine everything is moved
from one director, /usr/doc (on partition /usr) to another, (on the
/usr/share partition, sometimes on onother machine altogether).
Every single package on my machine has some files
affected. Heven help me ith there is a bug in the sctipt, or if
something happens to the sytem in the middle of this large move
Yes, one may argue that the script shall not have bugs, and my
response is depending on not having bugs is poor practice.
I would much rather evolve to FHS compliance, at the
adminstrative detail that makes sense for debian: on a package by
package basis.
Ian> In my proposal, there is no such day. Every system can independently
Ian> choose when to switch to the new layout, if at all.
And every system has to undergo a massive change some day,
rather than changing evolutionally.
Ian> Can you rephrase your objection ? Or you could explain what you mean
Ian> by `flag day' and why you think they (as you define them) are a bad
Ian> thing, though I think that'll lead to an unhelpful sidetrack.
Did that help?
Ian> ...
>> * Does not need a script for transition;
Ian> I don't see this as a big advantage. The relevant script is not that
Ian> difficult. I'll even volunteer to write it.
Requiring a script that needs to be run that affects files
belonging to every other package on the system, and moves them
around, is conceptually a bad solution.
>> transition happens on
>> a package by package basis, not a siter basis.
Ian> I don't see this as an advantage. It's certainly the key difference
Ian> between your proposal and mine.
The package is the unit of change, the unit of adminstrative
control, for Debian. It is natural for us to make large changes based
on changing packages one at a time, and not requirte major flag days
when the universe changes. (The Universe, for me, is my machine)
Ian> `supposed to be'. I think that my scheme, which copes better with
Ian> version skew, is superior in this respect.
In theory, maybe. In practice, I think the evlutionaly schem
is certainly no worse that the move everything on a flag day scheme.
>> * Move to /usr/share is held off for a bit, but when it
>> happens, it can be transparently gradual.
Ian> Why is moving an individual system to /usr/share gradually a good
Ian> thing ? Surely if you were running your own system by hand you'd use
Ian> a symlink, and then move the files all at once ?
Becasue I shall have no choice, if the idiocy of the vendor
left me, a sysadmin, to have to deal with the problem. I contend that
the vendor can indeeddo better, and evolve a system gradually (with
less chances of a catastrophic failure. Large changes risk large
failures. Let is not ordain large changes on every Debian system out
there.
Ian> For example, consider the case where /usr/share _is_ a different
Ian> filesystem. In your proposal the data volume moves gradually from one
Ian> partition to another, which is a distinct disadvantage.
This is true whenever I install packages, the used bits of the
partitions change. Since it happens but slowly, I have more time to
notic and address the issue.
Ian> With a separate copying script it could notice the directories
Ian> are on a different filesystem and point this out when offering
Ian> to move them, and it could even check that there will be room.
With a major move like that, you shall almost have to do
that. Hmm. The complexzity of the script maybe higher than you seem
to imply earlier. Increasing the complexity inrease chances of
failure.
Ian> I think that the most robust and best distribution will be
Ian> obtained if we don't put the work of many different developers
Ian> on each others' critical paths.
In general, this is a truism. And with every generalization,
there are exceptions. This may be one. With the time frame envisaged,
and the number of information browsing packages compared to the total
number of packages effected, I do not foresee the dire delays you
seem to see.
manoj
Ian> [1] Apologies for the poor formatting of Manoj's message in my quoted
Ian> text, which has resulted from my undoing of the awful `SuperCite'
Ian> quoting style, which even the author of SuperCite now admits to have
Ian> been a bad idea.
well, some of us, daring to disagree with the author, still
find the quoting styles aid the clarity of dialogue. However, this is
highly subjective...
--
"Problems are only opportunities in disguise." -- Albert North
Whitehead
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: