Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
On Thu, 2014-01-02 at 17:22:33 +0000, Jonathan Dowland wrote:
> You raise some very valid points and §I appreciate your concerns and
> perhaps should rephrase my request so that I'm suggesting subsuming the
> most common used features of debsign and perhaps as part of a staged
> migration (compat symlink to debsign binary name in the phase 1, real
> name dpkg-sign or whatever), to try and avoid further complicating the
> debian package development universe.
> On Thu, Jan 02, 2014 at 11:03:04AM +0100, Guillem Jover wrote:
> > IMO having debsign become a thiner wrapper around this new tool would
> > be the goal, as it would simplify its code,
(Obviously, assuming devscripts maintainers would agree, I was just
inferring from previous interactions regarding debuild for example; in
any case what happens with debsign would be their decision entirely.)
> > people not wanting to use
> > debsign could use the dpkg tool directly, and people not wanting to
> > learn new stuff could keep using the wrapper w/o regressions.
> That would not address the concern I raise: the surface area of debian
> package development tools would continue to grow, meaning people would
> use the non-recommended tool if they did not know better (or relied on
> documentation which had not been updated).
Honestly, I've been struggling a bit trying to understand this concern,
because to me that reads as suggesting no new features, command-line
options or tools should be added (to dpkg or devscripts or similar
packages), to avoid increasing the packaging tools surface area, when
in this case usage of this tool would be completely optional, and might
make life easier for some people. I don't see either the problem of using
one or the other, or one being more recommended than the other. If a new
tool would get added to dpkg every second week, then I could see it, but
not with the current pace.
If it was just a “hey, please consider creating a single interfaces that
can cover all current usages, and drop the old one if possible”, sure
I'm all for integrating back stuff that has been developed or prototyped
elsewhere, and trying to end up with a single interface by deprecating
the old interface if necessary. In this case though, I think debsign
(and debuild, and other similar wrappers) add value, and have features
that I don't see fit in dpkg proper, or might serve as future playground
to try out new stuff that could get merged back too. So in this case I
don't see its deprecation as desirable (but again that's something for
the devscripts maintainers to decide).
> [1] haven't checked whether they, in turn, rely on debsign.
They do, as well as many tools that need to control the signing
process, some mentioned in this thread.
Thanks,
Guillem
Reply to: