Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Hi,
>>"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 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. If
less than 1k inodes are resaourse problem, then the machine is
seriously swamped.
Chris> directory entries), and can cause severe problems if there are
Chris> more than some small number (five, I believe) of pending
Chris> symlink lookups. This is not an area where the kernel is
Chris> outstandingly robust.
Could you elaborate on this, please? Pending symlink lookups
where? I tried running 6 processes just doing symlink lookups
continuously, and nothing seems to be going wrong that I can see.
Chris> Granted, the latter is unlikely to come up in practice, but it
Chris> *is* a genuine potential technical problem with this proposal.
Can you point me to some documentation about this problem?
Chris> And the former is a very real issue, even an important one to
Chris> some people. This proposal may be more *aesthetically*
Chris> pleasing than a gradual-migration without symlinks, but it is
Chris> NOT better in a technical sense -- it is worse.
Depends on how hosed the kernel is wrt symlink lookups.
Chris> I know of *no* such technical problems with the simple migration,
Chris> package-by-package, with no symlinks involved, solution.
There is a quality of implementation issue involved.
>> 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
if the Linux kernel is fraginle in this regards, then we may have to
rethink it.
Chris> For now, I am formally objecting to this proposal. I am not
Chris> adamant; I am open to debate.
That makes two objections.
Chris> I actually prefer the aesthetics of this proposal, but it *is*
Chris> technically inferior, and I am angry that it is being promoted
Chris> as technically superior.
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> I would *very* much like to see some other proposals on the table.
Chris> Personally, I would rather have dpkg (or maybe base-files?) be in
Chris> charge of placing the doc directories in the appropriate place at the
Chris> appropriate time.
I tend to be wary of grand change everything at once with all
packages solutions. The upgrade granularity in Debian is the package,
and I think it is imperative that we allow for partial upgrades and
downgrades, and install a solution that recognizes that the upgrades
to Debian happen a package at a time, and can take a long time to
accomplish.
Chris> I realize that there are *political* problems with
Chris> this idea, but I think it is both technically *and* aesthetically
Chris> superior to gradual migration, package-by-package, with or without
Chris> symlinks.
I beg to differ. Espescially as dpkg has problems with
symlinks being relaced by dirs. In general, changes that can be
rolled back, are incremental, can be checkpointed, and can be
incrementally rolled back are far to be preferred over a Boom! Bang!
all at once change. And I am speaking technically, and from
experience with large scale migrations.
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.
Chris> So, if no better proposals come forth, and it becomes clear that
Chris> people *do* understand that this particular proposal *is* a
Chris> technically inferior one, but the general consensus is that the
Chris> aesthetics are more important, then I'll probably be willing to
Chris> withdraw my objection. But not until then.
Very charged words. I do not agree that this is an technically
inferior proposal (it may be unworklable, if the kernel is fubar'd,
but a gradual change that allows for backwards compatibility, and
allows the doc apckages time to change, is, IMHO, far from
inferior. )
manoj
--
Dyslexia means never having to say that you're ysror.
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: