On Wed, 7 Jan 1998, Richard Braakman wrote: > Dale Scheetz wrote: > > > I believe that if these fields are provided in the "package" paragraph, > > that dpkg should automatically include them in the control fields for the > > package. > > So do I. I don't see any reason why it should not. > > > On the other hand, what's 4 characters in the rules file cost? > > Well... I can think of a couple of costs :-) > > - All maintainers have to go check their rules files and add this flag.
This is a good thing. I encourage everyone to periodically look at the rules file for each of your packages. I keep a check list of these sorts of issues that I go over when I make a pass at my packages. Admittedly just because I do it this way doesn't mean it's the best way for everyone. (or even for me ;-) > - Inevitably, many will forget or won't notice, so someone will have > to spend time filing bug reports and chasing after maintainers. Sounds like a lot of exercise (with all that chasing) which is something I could use more of ;-) > (Consider how long it's taking to get the changelog and copyright > files named right in all packages) It is interesting that you choose this example. I saw that as one of the most positive uses of the bug tracking system for the year 1997! All funnies aside, the bug tracking system is *the* method for resolving such issues, whether the bug report is against dpkg or the packages that fail to provide fields is another matter. I would say that if you submit a bug against dpkg *and* all packages that don't provide it, it is even money as to which solution will be implemented first, but closure will eventually happen. > - It will be one more thing that new maintainers can get wrong about > a package. We should have a list ;-) While I admit that unnecessary complication causes unecessary error. This is all "pretty well" documented, and as changes happen (like new policy) the documentation should be made to properly track those changes. (we are actually doing a much better job in this arena than we have historically and this causes a problem in itself) As a "not so new" maintainer, the recend changes in the documentation have made it harder for me to keep track of "what the current policy" actually is. I read the packaging guidelines from cover to cover when they first came out, and used that information to convert my packages to the new source format. I found that task quite straight forward, at the time, and still find package construction to be a very clean process (without any helpers thankyou...). Only by watching discussions like this, on the lists, and making an "action item list" from those discussions, can I hope to keep my packages "up to date". The fact that I fall behind, and miss things on the lists (dispite my best attempts) makes me more and more reliant on the bug tracking system to keep me in line on these issues. ******* What we need first is a policy statement on the issue (policy statements should not declare implimentation details unless absolutely necessary) so that bugs can be filed against dpkg and packages that don't already supply the new policy. Looking back over the last statement, I find that I have fallen into "the policy" trap myself. That is, it is a trap to use policy to dictate bug reports. I heard someone say recently that all bug reports should quote the paragraphs in the policy document that qualify/quatify the bug. The implication here is that the only valid bug report is one based on our policy statements, which completely ignores "brokenness" issues, as well as other reasons for bug reports. I would clarify the statement with "only if the bug is addressed by Debian Policy..." Given that, I guess the quickest approach would be to file a bug against dpkg and begin policy discussions. That should give most of us time to impliment the new policy before it is declared ;-) and those of us who don't get to it can recieve bug reports. If the dpkg maintainer agrees that it should get fixed soon and has the time to work on it, we may even see dpkg deal with the problem seamlessly. Waiting is, Dwarf -- _-_-_-_-_-_- Author of "The Debian User's Guide" _-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .