Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
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:
> I'd feel very uncomfortable doing that, because it would mean, at least:
>
> * introducing a core dpkg tool within a different namespace
So dpkg-sign (or dpkg sign if you ever decided to move to internal
namespacing, which seems to be fashionable) with a compatibility symlink
to debsign would resolve this one,
> * having to parse a devscripts specific configuration file
That's more awkward, I'd agree, but you could support the command-line
arguments without supporting the devscripts configuration file. It could
be confusing for those who have relied upon it, though. A more
considered migration would be necessary.
> * having to support DAK specific .commands signing
That could be awkward, although the format is very similar (if not
identical) to debian/control and only one header is of interest. I
imagine most people use dcut/dput nowadays[1]
> * having to support remote signing
It would be fair enough to stderr "not supported, please use the older
tool in devscripts" and error 1 if such an argument was provided. That
would be pragmatic if (as I suspect) -r is rarely used.
> IMO having debsign become a thiner wrapper around this new tool would
> be the goal, as it would simplify its code, 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).
[1] haven't checked whether they, in turn, rely on debsign.
Reply to: