/usr/doc issue
Ok, now that all the administrivia is out of the way (we have a chairman,
and we'll soon have the list being archived properly), it's time to
focus on the proposal.. er.. many proposals which have been presented
to the committee about this FSSTND -> FHS migration issue.
[Aside: the issue of how to migrate from FSSTND -> FHS is a technical
policy issue, and so is within our scope.]
First off, we have a request by Wichert to choose one of the various
proposals which have been made on debian-policy. Also, we have proposals
by Manoj, Ian, and Chris Waters which I'm going to take as distillations
of the discussion which has taken place on debian policy.
Since I'm supposed to be charing this discussion, and I wanted to make
sure I'm doing this right, I started to conduct a personal review of
the debian-policy discussion -- to see where things stand.
(*) debian policy 3.0.0.0 was ratified (which specifies the use of FHS
in place of FSSTND) but it did not address how to manage the migration
between the two standards. The implication is that all packages which
have not yet made the migration are now non-compliant with policy.
This seems to me to be fundamentally wrong -- policy should never have
been ratified which says that every existing package violates policy.
Policy should typically represent the best of existing practice..
So I went to look at what the constitution said about such policy. What I
found surprised me: According to the constitution, the developers do not
have the power to set technical policy. This means that technically all
work done by the debian-policy group other than "documents describing the
goals of the project, its relationship with other free software entities,
and nontechnical policies such as the free software license terms that
Debian software must meet." are in some sense unconstitutional.
[[I think this was what has been upsetting Manoj so much..]]
However, the debian policy folks have been putting a lot of work into
formulating good policy. Also, it's *not* the job of the technical
committee to formulate [technical] policy -- we're just supposed to be the
first decision point for ratifying policy [once we've made up our minds
the developers get to overrule us if enough think we've decided wrongly.]
[[In the past, I've held the position that the debian-policy list has
the same authority as an individual developer: they're the package
maintainers for debian-policy, so they have considerable latitude in
making decisions about what goes in the debian-policy package. However,
declaring that existing packages are buggy clearly overlaps with the
authority of other developers which puts it squarely in our laps.]]
In general, I'd like to recommend that we ratify all decisions made by
the debian policy group on technical policy, as long as those policies
don't declare existing packages which were compliant with previous policy
versions to be non-compliant with policy. I expect we'll discuss this
further, shortly.
Ok, back to my review of the debian-policy discussion: It turns out
that there are packages which refer to the contents of /usr/doc/,
examples include xfig (which refers to its own /usr/doc/ entries) and
dwww (which refers to the entire hierarchy. [Also, there may be userland
programs which refer to /usr/doc/ -- but I didn't see any discussion of
this when I was skimming over the policy discussions.]
======================================================================
Aside: we are responsible for deciding on technical policy. By not
electing a chairman earlier, and by not issuing any advice to the policy
folks we've allowed this situation to develop. So while the policy
group has made some mistakes here, so have we. This is important to
keep in mind when thinking about how to react to this situation...
I think that from this viewpoint the situation is very clear:
(*) inappropriate policy has been issued.
(*) a number of packages have been modified to comply with this policy.
(*) "existing practice" now includes this state of affairs.
======================================================================
Because this point of view is so radically different from what I held
earlier, I'm going to leave this issue open for discussion at least
until tomorrow (that is: I'm not drawing up the ballot quite yet).
I want to make sure I've not made some incredibly stupid mistake before
we vote on this.
However, at the moment, I'm inclined to put the following options on
the ballot:
(1) reject the current 3.X policy, pending further discussion.
(2) ratify the current 3.X policy.
(3) ratify the current 3.X policy but declare that /usr/doc/ shall
continue to be used in place of the FHS mandated /usr/share/doc/.
(4) ratify the current 3.x policy but declare that /usr/doc/ may be used
in place of the FHS mandated /usr/share/doc/ (at the developer's option).
(5) ratify the current 3.x policy as in (4) above with the additional
requirement that all packages must be modified so that they provide a
symbolic link so that their contents can be accessed from either
/usr/doc OR /usr/share/doc.
Note that (5) carries with it the same flaw that 3.0.0.0 originally had:
it declares that every existing package is buggy.
Note that (4) is pretty close to the status quo (doesn't declare any
packages buggy), but doesn't really address any of the technical issues.
While (3) has a certain esthetic appeal, I don't know if there are other
migration issues lurking out there. If we go with (1) instead of (3)
we have a sort of moral obligation to review the policy for other flaws
and get it off our plates as fast as possible.
Of course, if we go with (2), then we're effectively declaring that most
existing packages violate policy.
======================================================================
Final notes: (1) is essentially Ian's proposal -- and yes, I'd include
the other details from his proposal on the ballot. (5) is essentially
Manoj's proposal and I'd include the details from his proposal as well for
that item. (3) represents Chris's proposal. (2) and (4) represent two
distinct interpretations of the "take no action" concept which several
people have mentioned.
As chairman, I don't get to declare which of these is the best decision.
And, I might have even made some major blunders in my analysis of this
situation. However, I do feel that we have an obligation to decide
fairly quickly on this issue..
Comments?
--
Raul
Reply to: