Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Hi,
>>"Chris" == Chris Waters <xtifr@dsp.net> writes:
Chris> 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.
Chris> I wasn't the one who said the bit in quotes, you were. Ok,
Chris> you've now raised a new point, and I agree with you that it's
Chris> a much better point, but it's *still* an aesthetic
Chris> consideration! The information is just as available if we use
Chris> two locations. There is nothing *technically* wrong with
Chris> using two locations; it's functionally equivalent, it's merely
Chris> somewhat uglier.
The fact that a single probe into the location derived using
the pacjage name is no longe guaranteed to work is indeed a technical
fault. Mreley repeating that it is not so does not make it
non-technical.
Chris> And in any case, it's not one location vs. two. It's more
Chris> like three or four vs. four or five. We have man pages, info
Chris> files, built-in help systems, dwww and dhelp, oddballs like
Chris> gnome-help, and, finally, as a point of last resort (at least
Chris> for non-masochists), we have the all-too-often useless
Chris> /usr/doc area.
The only one in consideration here is the /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.
Chris> I didn't say that was a *strong* technical flaw. I merely
It is not, IMHO, a flaw. The Debian installation requires hard
drive space is a requirement, not a flaw. Same here.
Chris> said that it was a technical flaw. Objecting that it's a
Chris> minor flaw doesn't make it not a flaw.
Calling a requirement a flaw does not make it a flaw either.
Chris> So far, you haven't presented a SINGLE technical argument in
Chris> favor of this proposal!
I am afraid that you are not reading my posts then. Read the
proposal; the specs for the transition were postred there.
Chris> [more than five pending symlinks and the linux kernel]
>> Could you elaborate on this, please? Pending symlink lookups
>> where?
Chris> First of all, I should make it clear that in practice, this is
Chris> probably even *less* important than the previous technical objection.
Chris> But it is, still, a *technical* problem, however minor.
Chris> I'm a little fuzzy on how this is triggered, though. I know it's
Chris> *not* triggered by a simple chain of symlinks, like:
Cool. However, as you say, in practical terms, this is
irrelevant. This is not a debating society. We are trying to
seekl real world answers, and I think we can accept the risk
of this exceeding bizzarre bug ever happening.
>> There is a quality of implementation issue involved.
Chris> There is an *aesthetic* quality of implementation issue involved,
Chris> yes. Both of the technical objections I raised are *very* minor.
Chris> They are, however, technical objections.
As I said, they are ignorable, for all the real world impact
they are likely to have.
Chris> How so? I see no additional functionality provided by these links.
Chris> The user still has to check several possible locations for
Chris> documentation (man pages, info files, etc.). And even so, the user
Chris> *can* still find the information, whether we have one location or six.
Chris> That's not additional functionality, it's simply easier and more
Chris> elegant. Functionally, it's IDENTICAL!
In other words, since the information is not all in one place,
adding yet another location is all right. I think not.
Chris> Again, I say, IF you ACTUALLY believe that aesthetics takes a
Chris> back seat, then you should withdraw this proposal.
Chris> Personally, I disagree with you; I think aesthetics can be
Chris> more important in some cases. I'm just not sure whether this
Chris> is such a case or not.
I still think that looking for the examples and copyright file
are enough to justify a one stop solution. Moving information and
having two different locations for this specific type of
insformation, which was under one dir, and shall be so again,
providing no such location in the transition is a technical flaw.
>> Apart from the kernel problems, I do think it is technically
>> superior. I must confess I was unaware of the pending symlink lookup
>> issue.
Chris> Please offer one single, solitary *technical* reason for the proposal.
Chris> You have not provided *any* yet. It's a very pleasing
I think I have. Please read the archives. Several peolpe are
of the opinion that having two different places to look for this
information is irritating enough to marr the distribution, and this
additional lookup not being avoided is indeed a technical oversight.
>> 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.
Chris> So? We do have a default plan we can pursue in the meantime.
Chris> We have people uploading packages that use /usr/share/doc
Chris> only, and the universe hasn't collapsed. There's nothing
So the only flaws we fix are the finalk grand collapse? This
is very silly.
Chris> *technically* wrong with our default plan; it's merely a
Bullshit.
manoj
--
I owe the public nothing. J.P. Morgan
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: