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

Re: debmake contains namespace pollution and bugs procedure

On Sun, 12 Oct 1997, Ian Jackson wrote:

> Christoph Lameter and I have been having a tussle over bug #7490 (also
> #5682 reported by Owen Dunn).
> In it I complained about debmake's namespace pollution.  Christoph
> renamed 'done' and 'ok', but left
>  uscan uupdate debi debc release todo build debpkg dch and debstdo
> He closed the bug report without further discussion.  When I reopened
> it he closed it again in a message saying:
> > These are not bugs. If you want to have a public discussion post to
> > debian-devel.
> I have the following objections - two procedural, one technical:
> 1. A bug report should not be closed unless all the things in the
> report have been addressed.  Christoph initially closed this bug
> without addressing the complaint completely.  I had to go and
> investigate the latest debmake package to determine whether to reopen
> the bug.

We still disagree about this. I still contend that the maintainer has
control over the package, and should have control over bug reports. While
I still hold this position, I agree that this situation is not entirely
satisfactory at times.

If we were to set things up so that only the report submitter would be
allowed to close their own bugs (which would still allow the maintainer to
manage his own "to do list" via bug reports), there would be bugs reports
that would never get closed, even after they had been fixed.

Committees like the Testing Group could adequately decide whether the bug,
as specified (assuming it's clear) has been repaired, but I wouldn't want
a committee assigned to deside which reports constitute bugs.

> 2. If there is a disagreement about a bug report the bug should be
> left open while the discussion about it takes place.  Otherwise the
> issue might be forgotten.  If people agree with me on this it should
> be made policy.
I think that, whether the bug report is kept open, or not, you chose the
correct avenue to address your grievance. Taking this issue to
debian-devel and eventually (or even initially) to debian-policy appears
to be the correct response to this situation. (It worked with the Pine

> 3. This namespace pollution _is_ a bug, and the consensus of those
> commenting on it is that this is the case.  All these binaries should
> be renamed to start with a common prefix.  I would object to the use
> of the 'dpkg-' prefix.  I suggest 'debmk-'.
I agree with Ian completely here. I would even settle for something more
compact like 'dm-' as long as all utility programs in the package. This is
going to become more important as the number of "utility" packaging
packages increases. Debmake was the first package to provide such
utilities, and should follow dpkg's lead in the use of a prefix to all
utilitie names. In this fashion there can easily be a dpkg-buildpackage
and a debmk-buildpackage, both on the system with no conflict.

Personally, I'd like to see this end up in the policy manual, although I
don't have the time to join any discussion there.

> I shall reopen this bug while the discussion takes place.
I would probably wait for a policy decission, but you are certainly
within your rights to reopen this bug report.


_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

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: