Re: please vote...
On 7 Aug 1999, Manoj Srivastava wrote:
> Hi,
>
> In case it was not clear, I, too, am voting for the "forest of
> symlinks" proposal. That makes two votes for it.
Why are we voting on a proposal that has not yet been accepted by the
committee?
As one of the two proposed candidates for the chair of this committee, I
would point out several points:
As noted in my reply to the original request, the alternative channels for
correcting this screw-up have not been exercised.
There is only one proposal before the committee, not the minimum of two
required to make a choice. (Yes, I read the proposal, but I submit that
since Manoj has already voiced his "vote" for the symlinks proposal, that
he is not an unbiased author for the section on "do nothing" ;-)
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 ..."
Neither side of the current debate has thought out the reasons, or the
concequences of their proposed actions:
1. Symlinks: There seem to be two reasons for the "need" for symlinks:
a. Least surprise to users looking for docs
b. Without it things break
2. Do Nothing: While not well represented, seem to be strong enough to
block the symlink proposal.
a. Is there really a problem?
b. What breaks?
As no one actually representing 2 has spoken to this committee, I must act
in that reguard and try to deal with the obvious:
If 1a is actually an issue, then the symlinks don't resolve the surprise,
they only pospone it. At some point the symlinks must be removed...right?
So how do you propose to resolve the "surprise" when they all go away at
once, when you couldn't resolve it going away gradually?
Asside from the user having to look in two places during the "transition"
what things break if no symlinks are provided? So far I've heard
suggestions that package helper scripts will fail because they don't know
about the new location. I submit that, under the current policy these
scripts are broken, should be bug reported, and should be fixed to comply
with policy...whatever that resolves itself to be. If we are going to
allow helper tools to stand in the way of progress, then what kind of help
are they anyway? The tools should be improved to handle transition
situations like this, rather than requiring global package mods to support
the tools through the transition.
Basicly it looks to me like the policy group got the cart before the
horse, and mandated conformance without determining any process for the
transition. Now the Technical committee is being asked to choose between
an unacceptable design and no design in order to resolve the problems
greated by the previously, not well thought out, policy change.
Reply to: