Re: please upgrade your packages to current standards
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: dwarf@polaris.net 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
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: