Re: Moving to the FHS: not right now!
Anthony Towns <aj@azure.humbug.org.au> writes:
> [1 <text/plain; us-ascii (7bit)>]
> On Wed, Aug 18, 1999 at 04:25:48PM -0700, Chris Waters wrote:
> > First of all, I'm still not convinced that this is a technical issue,
> > as I mentioned in my objection to Manoj's proposal.
> "How do we keep all the documentation `together' while we physically move
> it from /usr/doc to /usr/share/doc?"
Is only an issue if we can't move it all at once *as far as our users
are concerned*. Let us not lose sight of the real goal here: to
produce the best *stable* systems! As long as all the docs are in the
same place in a stable release, who *cares* what kind of ugliness was
involved in moving them? Unstable is *supposed* to be, er, unstable.
> That's the technical question. The question "Do we want to?" (presumably
> answered "Yes, if at all possible") otoh, is definitely an aesthetic
> question. I presume you don't disagree with my answer, though?
I think you're ignoring the issue of stable vs. unstable, but
otherwise, no, I have no strong disagreements with that. However, I'd
much rather sacrifice the aesthetics of unstable *if* the end result
is a better stable system.
Note that I'm the first person to come along and try to get specific
releases mentioned in policy. That's because I believe that our
releases are, ultimately, the most important product of the project,
and I think that should take precendence over just about everything
else. I'd much rather have odd exceptions listed in our policy
document than have odd exceptions embedded in our releases!
> It may well not be possible, but so far at least, the symlinks idea
> (Bug#40706) seems to have no major problems.
*None* of the proposals (I think we're up to four now) seem to have
*major* problems. However, the symlinks seem unnecessary to me,
*unless* we want to make unstable more consistent, at the cost of
making stable somewhat uglier, and unless we want to add *permanent*
overhead to all packages for all eternity (or at least the next three
or four releases, minimum).
> > Oh, and I did point out a couple of very minor, but still ACTUALLY
> > TECHNICAL objections to Manoj's proposal. Executive summary: symlinks
> > have limitations, and if we add an extra layer of symlinks, we
> > increase the (admittedly minor) risk of bumping up against those
> > limitations.
> "Symlinks have limitations. Therefore we shouldn't use symlinks."
That's not what I said. The second sentence is purely a construct of
your imagination.
I'm not a huge fan of the symlink proposal, no, but this is not why.
I'm not a fan, because it seems to consider unstable to be more
important than stable.
Personally, I would rather have a funky, inconsistent unstable system
as *long* as the end result is a cleaner and consistent stable system.
Adopting the mandatory symlinks (and it's primarily the mandatory part
I object to) would basically *require* us to have these symlinks in at
least one stable release. I would rather avoid that if possible. It
also requires a lot of unfortunate overhead for all packages, which I
would also rather avoid if possible. Many packages currently have no
postinst. The mandatory symlinks proposal would (eventually) require
all packages to have postinsts.
But that's mostly aesthetic objections. I agree that this is
primarily an aesthetic issue, and I'd like to avoid releasing an
inconsistent stable system, and I'll even back the symlinks proposal
if that really seems to be the only approach which will get us there.
But I don't believe it is. If we're willing to put up with an
inconsistent unstable system, I think we can get everything moved by
the time Woody is released. If nothing else, we can set up the
autobuilders to move the dirs and repack the debs.
(Detailed and irrelevent analysis of the symlink technical limitations
elided.)
I think we're losing sight of the real goals here. I think we need to
get back to focusing on the *stable* systems, and how to make them the
best they possibly can be.
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: