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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140102172233.ga7...@bryant.redmars.org
