[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Moving to the FHS: not right now!

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. 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. :-)

The argument is that there may be user authored programs or procedures
which use the (admittedly simple) /usr/doc interface.

However, it's true that we don't have a well developed criteria for
determining what is and isn't a technical issue.  [For example, my wife
would say that even user interface issues are technical -- but then
she needs my daughter's help when browsing the web.]

> 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.


> 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.


Thanks for being level headed,


Reply to: