Re: what needs to be policy?
Manoj Srivastava wrote:
> Joey> 1. A package is broken. It does not work, or it does not install, or it
> Joey> breaks other packages that depend on it or use it, etc.
>
> I have reservations about the last bit (I would like to see
> the wording tightened a bit), but I understand.
>
> Joey> 2. A package is in violation of policy.
>
> Joey> Can we both agree with that statement? I would like to find I
> Joey> agree with you at some level.
>
> Joey> Of course, you know I'm going to add:
>
> Joey> There is no need to add an item to policy if a violation of
> Joey> said item would allow a bug report to be filed for reason #1
> Joey> above.
>
> Of course there is a need, if you want it to be a policy of
> Debian. Unless it is policy, there is no compelling reason for
> packages to conform
You still don't understand me? Now that we have points 1 and 2 clarified:
There _is_ a compelling reason to conform even if it is not policy; because
maintainers have an obligation to ensure thier packages work, otherwise
people will have a legitimate reason to file bugs against said packages for
violating point #1 above.
> (I think I shall close the doc-base bugs on my
> packages, they annoy me).
I think this is a bad example because these bug reports are wishlist (not
covered by rules 1 and 2 above) and doc-base isn't in policy.
> I think we need to create standards that packages follow, so
> that one may depend on things being a certain way on Debian boxes
> (like location of the MTA program, and that /var/www means something
> vis-a-vis the local hosts).
I have never argued that the fsstnd/fhs should not be in policy. This is
exactly the type of thing that _must_ be in policy because if it's not we
have no way to take the violators to task.
> If you understand my stance, and still hold thse vierws (and
> thus ensure me we are on the same page, more or less), then I see
> what you are saying, yes. I think I disagree with your conclusions,
> as you do mine.
That's fine. Once we understand each other's view points we can really start
to discuss the pros and cons of each. Some of my problems with your concept
of what policy should be are these:
Policy is a document that all maintainers are supposed to become familair
with, and that they must work to keep familair with as it changes. I see
your proposals doubling the size of policy, which is going to raise the bar
of who can even keep it all in their head.
I think that your requirement for formalization of everything is going to
stifle innovation. Going back to the menu package example, I have considered
hacking in a new, cleaner menu file format (while of course retaining
back-compatability). If the old one were policy, this change would be
disallowed until I went through the rigamarole of changing policy, if I even
could.
--
see shy jo
Reply to: