Re: Moving to the FHS: not right now!
Raul Miller <moth@debian.org> writes:
> (3) The message from Wichert was incomplete -- the technical committee
> does not do detailed design work. However, two people have stepped
> up with proposals to address that lack. Briefly: Manoj Srivasta
> has proposed a mechanism which would allow us to move forward on FHS
> migration from the current messed up state of things, and Ian Jackson
> has proposed that we revert to FSSTND until the issues can be sorted out.
Hi,
First of all, I'm still not convinced that this is a technical issue,
as I mentioned in my objection to Manoj's proposal. The information
is just as available whether it's found in one location or two, so I
don't see any technical problems here. It's an ease of use issue,
which, to my mind, is an aesthetic matter (albeit an important one),
not a technical one. I mean, heck, we're allowed to use sed, even
though awk and perl are easier to use and read, IMO. :-)
I almost hate to mention this, because I'd love to see the issue
resolved *somehow*, even if it's to have a proposal I dislike mandated
by fiat. But I'd hate to set an unfortunate precedent. If it's not a
technical issue (and I don't believe it is), then it's not a matter
for the tech committee.
And if the tech committee *does* decide that this is in their purview,
then I'd like to point out that I have a proposal on the boards as
well, to wit, stick with /usr/doc (but continue migrating to FHS
otherwise) until Potato is frozen. See Bug#42477. This is similar to
IWJ's proposal, except that it allows us to continue working on the
not-so-user-visible FHS-compliance issues in the meantime.
Also, some have proposed that we ignore the issue and simply continue
to migrate package-by-package. This is not my preferred solution, but
I don't think it's so unreasonable that the tech committee should
ignore it. I find it aesthetically unappealing, but technically
robust. No bug number, because this is the default that will happen
if policy isn't changed.
So, there's really four proposals, not two.
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.
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: