Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Manoj Srivastava <srivasta@debian.org> writes:
> >>"Chris" == Chris Waters <xtifr@dsp.net> writes:
> Chris> Which leaves the "user is used to '/usr/doc'" objection, which is a
> Chris> *purely* aesthetic objection, not a technical one
> You are missing the point. It is not that users prefer one to
> the other, the objection is that there shall not be any one place for
> the users to look into.
I wasn't the one who said the bit in quotes, you were. Ok, you've now
raised a new point, and I agree with you that it's a much better
point, but it's *still* an aesthetic consideration! The information
is just as available if we use two locations. There is nothing
*technically* wrong with using two locations; it's functionally
equivalent, it's merely somewhat uglier.
And in any case, it's not one location vs. two. It's more like three
or four vs. four or five. We have man pages, info files, built-in
help systems, dwww and dhelp, oddballs like gnome-help, and, finally,
as a point of last resort (at least for non-masochists), we have the
all-too-often useless /usr/doc area.
> >> I understand that the forest of symlinks is ugly, but it is
> >> technically sound,
> Chris> No, it is not. It consumes unnecessary resources (inodes,
> Most machines have less than a thousand packages installed.
I didn't say that was a *strong* technical flaw. I merely said that
it was a technical flaw. Objecting that it's a minor flaw doesn't
make it not a flaw. So far, you haven't presented a SINGLE technical
argument in favor of this proposal!
[more than five pending symlinks and the linux kernel]
> Could you elaborate on this, please? Pending symlink lookups
> where?
First of all, I should make it clear that in practice, this is
probably even *less* important than the previous technical objection.
But it is, still, a *technical* problem, however minor.
The limitation can be found in fs/ext2/symlink.c, in the function
ext2_follow_link(), where it says:
if (current->link_count > 5) {
iput (dir);
iput (inode);
return -ELOOP;
}
(Nice, eh? Not even a symbolic constant, just a hard-coded `5'.)
I'm a little fuzzy on how this is triggered, though. I know it's
*not* triggered by a simple chain of symlinks, like:
a -> b, b -> c, c -> d, d -> e, e -> f, f -> g, g -> h
I *believe* that a pending symlink happens when the inode of what a
link points to cannot be found without resolving another symlink
first. In the case above, the inode of `b' can be found right away --
it's a symlink, but its inode can be found, so `a' doesn't pend.
However, in a case like:
a -> b/c, b -> d/e
the inode of what `a' points to (`c') cannot be found until the
symlink `b' is resolved. So `a' pends on `b'.
I *believe* that's how it works, but for the actual details, well,
UTSL. :-)
> There is a quality of implementation issue involved.
There is an *aesthetic* quality of implementation issue involved,
yes. Both of the technical objections I raised are *very* minor.
They are, however, technical objections.
> >> I submit that aesthetics takes a back seat to functionality.
> Chris> If so, then you should withdraw this proposal.
> No. Functionality is indeed enhanced by this proposal, though
How so? I see no additional functionality provided by these links.
The user still has to check several possible locations for
documentation (man pages, info files, etc.). And even so, the user
*can* still find the information, whether we have one location or six.
That's not additional functionality, it's simply easier and more
elegant. Functionally, it's IDENTICAL!
Again, I say, IF you ACTUALLY believe that aesthetics takes a back
seat, then you should withdraw this proposal. Personally, I disagree
with you; I think aesthetics can be more important in some cases. I'm
just not sure whether this is such a case or not.
> Apart from the kernel problems, I do think it is technically
> superior. I must confess I was unaware of the pending symlink lookup
> issue.
Please offer one single, solitary *technical* reason for the proposal.
You have not provided *any* yet. It's a very pleasing proposal
aesthetically (although it would be more so if it weren't for man
pages, info files, etc.). But not one bit technically superior that I
can see. Either you're hiding something, or you have a very different
definition of "technical" than I do.
> Chris> I think it is *very* possible to come up with a better
> Chris> proposal which actually works. But I'm not making one myself,
> Chris> as it requires more effort than I want to spend at the moment.
> I see. I am sure if we sat and pondered over this for a decade
> or so, we couild indeed come up with a better solution.
So? We do have a default plan we can pursue in the meantime. We have
people uploading packages that use /usr/share/doc only, and the
universe hasn't collapsed. There's nothing *technically* wrong with
our default plan; it's merely a question of aesthetics. So I have no
problem sticking with the default for now and waiting to see if a
truly better plan *does* come along.
The problem I have is that you're presenting this plan which has some
very minor technical flaws, and a great deal of aesthetic appeal, and
then arguing that we should ignore aesthetics.
I don't want to be an ass, so, if everyone agrees that aesthetics are
more important in this case, I'll withdraw my objection. Or, if you
come up with a solid technical reason to prefer this plan -- one that
doesn't merely involve dubious arguments about "ease of use" -- I'll
withdraw. So far, I've seen neither.
cheers
--
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: