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
