Re: FHS - transition
Ian Jackson wrote:
> 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.
If your concept of "flag day" includes the idea that all debian systems must
change at a given time, it's impossible for a flag day to ever occur in
debian bacause debian sysyems are upgraded whenever their admins get around
to it, which might be years from now.
> I don't see this as a big advantage. The relevant script is not that
> difficult. I'll even volunteer to write it.
[ and later ]
> 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.
So you agree this script isn't so simple after all. It has to deal with
various sorts of failure conditions, it probably has to interact with the
user to clear some of them up. I'm sure it can be written. But how well is
it going to be debugged, and can we trust it to work under every condition?
I'd rather trust dpkg which we know will work.
> > * 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 ?
The fact is, dpkg allows us to do things you couldn't do if you were
maintaining your system by hand. Just because sysadmins everywhere use
kludges like symlinks doesn't mean they're the best way to do things when
dpkg gives us an alternative.
> > 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) ?
Libc5: 90-some, all of which are either
a) altdev packages
b) libc5 compatability libraries
c) packages in non-free for which we have no source.
Libc4: 0
The transition is as complete as is possible, and we did it incrementally
with many developers in each other's critical paths. It was painful but
we've shown we can do it. Moving a doc directory incrementally is going to
be a breeze by comparison.
--
see shy jo
Reply to: