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

Re: Resolving policy and practice wrt sbin directories (traceroute)

    Hello Anthony,

On Mon, Jun 25, 2001 at 05:43:38AM +1000, Anthony Towns wrote:
> Find some perspective, and worry about something that actually matters
> instead? This ain't the end of the world, it ain't the camel's straw,
> and it ain't the ladder leading towards a slippery-dip.

    I respect your sentiment, but I find it lacking.  Arguably, my
maintenance of a non-free game and two admittedly minor tools does not
actually matter either (that is, they do not have a major impact on the
distribution).  Does this mean that I should resign from the project?  Does
it mean that I should free to flagrantly break Policy on those packages (wrt
the FHS anyways -- an action that doubly doesn't matter) because they don't
actually matter?

    Should I argue that since there is nothing of serious import that I am
currently doing for Debian I can spend my time doing these unimportant

    More to the point, I think this does matter.  Doesn't anything having to
do with the application and interpretation of Policy matter?  Isn't that the
whole point of Policy?  If it doesn't matter, should it really be in Policy?
Should we admit that we are applying Policy in an inconsistent manner
because we don't think that it matters?

    You see, this is the crux of my concern.  Our users will read the Policy
Manual and see that we have promised FHS compatibility.  Upon discovering
that there is something that seems to belie that, they will complain,
sometimes to debian-devel and spark another round of arguments.  Our
reputation as a distribution that does things right[1] (or more accurately,
I suppose, that follows its own rules) will be damaged and we will lose the
respect of our users (and probably some users as well, although I make no
claims that it will be a lot -- this is pure speculation after all).  We may
have been able to claim that we didn't notice that this was a
Policy-breaking issue before (assuming that no one else has noticed this
before), but now that I have posted that information to -devel and -policy,
we can't do that any longer.

    If that is not convincing, then what about forestalling the
traceroute/FHS argument on debian-devel?  Doesn't that matter?  I expect
everyone here agrees that it will return if the status quo is not changed.
I believe that changing Policy will probably reduce the length and frequency
of the arguments (since we will have Policy to cite), and certainly changing
the package(s) will be even more effective.

    Is the cost too high?  This amounts to (for one of the options anyways)
changing one word in Debian Policy.  I have agreed to draft the Policy
change (such as it is, I don't expect it to be a major burden!) and am not
doing anything else important for Debian anyways (if you accept my
hypothetical above), so how is this anything but a win for the project at
large?  Surely we are wasting more time and resources on these arguments
than we would expend on getting Policy changed.  (Now if we were to go the
other route [changing the actual packages] then that is a reasonably
expensive endeavour, I grant.)

    Is this not a slippery slope?  We are ignoring Policy for no good
reason.  Even expedience is not being cited by the argument above, and would
hardly preclude changing Policy.  Would it not be reasonable for a
maintainer to cite this decision when they don't want to follow Policy?
Does this not encourage maintainers (especially new maintainers) to silently
break the FHS (or other aspects of policy) without even bothering to discuss
it with others because it has been done before?  Perhaps that is not what
you meant by slippery-dip; I am not familiar with that particular idiom.  If
I have misunderstood (or my argument is flawed, or any of my arguments are
flawed), please illuminate me or point out the flaws in my argument.

    Please allow me to answer my own question:

    If it is written in Policy, then it matters.

Rene, who thinks that it follows that if it does not matter, it should not
    be written in Policy, which is another way out of this mess.

[1] I recognize that there is a reasonable argument that leaving traceroute
    where it is is the "right thing" to do, but in this context I believe it
    is not since Policy dictates otherwise.  I parenthetically note that I
    have not yet noticed an argument that a symlink or wrapper is not the
    right thing to do, however.

+---           (Rene Weber is <rene_autoreply@elvenlord.com>)          ---+
| "The real purpose of books is to trap  the  mind  into  doing  its  own |
| thinking."                                        -- Christopher Morley |
+---  E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/>  ---+

Attachment: pgpSiQWpoXjiT.pgp
Description: PGP signature

Reply to: