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

/usr{,/share}/doc structure proposal (was Re: please vote...)



Dale Scheetz <dwarf@polaris.net> wrote:
>  >> The current "problem" has been caused by a recent policy decission that
>  >> was malformed. "Thou shalt be FHS compliant" is not, and never should be
>  >> considered, an adequate policy statement. I suggest that the policy group
>  >> remove such statements, and replace them with "In order to become
>  >> compliant with XXX, developers will need to impliment the following
>  >> proceedures ..."

> >>"Raul" == Raul Miller <moth@magenta.com> writes:
>  Raul> This idea really appeals to me.  We might want to excercise our advice
>  Raul> power and make a statement to this effect [once we have a chairman.]

On Mon, Aug 09, 1999 at 10:27:25AM -0500, Manoj Srivastava wrote:
>         Objections:
>         a) This would be a duplication of the material already in the
>            FHS, where it is presented coherently, and has rationale,
>            and all

No.. or, I'm not sure exactly what Dale was thinking, but I was not
thinking that we should provide material redundant to the FHS document.

I was thinking that we need to be careful where there are multiple valid
interpretations of the FHS document.

>         b) Details like this should not be in policy; it is already
>            getting too large for a mandatory document, and it is
>            accepted practice to have ancilliary documents that are
>            referred to by policy. The FSSTND and FHS are one of
>            those. 

Now, this I have a longstanding agreement with -- in my mind the Debian
Policy document should be split into at least two documents: one which
is just broad statements of policy, and a much larger document specifying
implementation details and such.  Or perhaps this should just be an
editorial change (with all the broad statements of policy in an Introduction
or Summary at the begining of the document).

But that's not really a technical committee issue (ok, maybe we'd
be within bounds to issue an advice along this line, but this
doesn't seem to me to be a technical issue).

>         c) Most of the changes in the FHS do not require this anyway,
>            things internal to a package, or where the changes are not
>            suer visible due to flexibility in interface (info, for
>            one) do not need a policy dictum. Only a user visible
>            change like this warrants it, wehre the interface is just
>            using ls or cat or a pager. 

Sure, and thinking about it the whole idea of issuing "policy" on
FHS ambiguity issues is already pretty much what we're doing in 
Debian policy -- so issueing an advice would be silly (redundant
and perhaps insulting).

>  Raul> [Aside: Personally, I'd like to have seen /usr/doc -> /usr/share/doc/.
>  Raul> and I'd have liked to see legacy systems left with /usr/share/doc ->
>  Raul> /usr/doc/.  However, it's too late for that -- presumably, as you say,
>  Raul> because policy didn't specify how FHS compliance should be achieved.]
> 
>         This is technically flawed, as it would break
>  upgrade/downgrades, depending on the direction of the link. The
>  lossage is dpkg removing documentation. There was an appendinx to the
>  proposal that details the experiments conducted which demonstrate
>  this. 

Yes, I remember this now, sorry.

>  Raul> I'll note that finding /usr/doc missing is far more likely to result in
>  Raul> someone finding /usr/share/doc than finding /usr/doc/mesa-doc missing.
> 
>         Change dpk hnot to remove the files, and we shall all be
>  grateful. But, in the meanwhile, this is a flawed proposal. 

[Oops, that last sentence of mine was meant in support of your proposal :]

>  >> >From my point of view this is not a technical problem, but a political one
>  >> within the policy group that can only be resolved there.
> 
>         You are wrong. The policy groups mandate is to make near
>  concensual policy amendments. The only recourse for controversial
>  techncial policy is this sommittee, or the vote by general
>  resolution. Voting on technical issues is not recommended.

Since you used the pronoun "You ", I'll assume that there's a significant
possibility you were addressing me (as opposed to Dale).  If so: I didn't
write that...

>  Raul> While I agree about the cause of the problem, we're not being asked
>  Raul> to solve the political aspects -- only the technical ones.  However,
>  Raul> your arguments have swayed me -- if we had a ballot (which we don't),
>  Raul> I'd probably be changing my vote to further discussion.
> 
>         I actually disagree about the problem (which does sound like
>  blame shifting, actually). The problem is that there is not light
>  weight process of making sontroversial changes to technical policy --
>  and even the process that is open depends on votiong, wihch is a bad
>  idea.

Careful here.  Allow me to artificially create some terminology:

We have a situation here, for which we'd like to see a solution.

There are many problems which are a part of the fabric of this situation.
[For example, the dpkg bug  which you reminded me of -- and the required
stability of the dpkg code base -- which results in a very slow release
cycle for dpkg.]

[I've got just a bit more to say, but I'll split that off into another
email.]

-- 
Raul



Reply to: