Bug#557459: dpkg-source: should not fallback to other formats without user intervention
Package: dpkg-dev
Version: 1.15.5.2
Severity: wishlist
It has been suggested on IRC that having dpkg-source switch back to
native mode if it can't find the .orig tarball was probably a bad idea
from the beginning and that it tends to confuse people. However,
with the addition of new formats, I generalized that concept of
fallbacks... we have a list of formats to try and the first one
whose prerequisite is satisfied is used. ron just found out that
passing -Zbzip2 generated a 3.0 (native) source package because
"1.0" accepts gzip only and that "3.0 (native)" is in the fallback list.
Now that we have native and non-native in different formats we have an
opportunity to fix that. We could just make dpkg-source fail if the
prerequisite for the current format is not satisfied. So people that
want native source packages would have to be explicit about that choice
and put "3.0 (native)" in debian/source/format.
Since that is an important interface change, I'm soliciting some more
feedback from debian-devel before I decide to do it.
On a sidenote, with such a change when "3.0 (quilt)" is made the default
format, 1.0 native source packages would fail to build because the
fallback to native would then be specific to 1.0. When we do that,
dpkg-source -x should thus be modified to auto-create debian/source/format
to mitigate this problem in this specific case.
Here's the log for reference:
00:02 <ron> buxy: I'm not sure sure this "fall back through a range of default
formats" idea is so hot.
00:04 <ron> if I pass -Zbzip2 to dpkg-source, for a package with no other
qualifiers, having it default to 3.0 (native) is far more likely to be
wrong than right
00:05 <ron> there is a perfectly good orig.tar.bz2 there, and a perfectly good
debian dir, so it seems quite unintuitive that it makes a native
package out of that
09:44 <buxy> ron: good remark, I can add 3.0 (quilt) before 3.0 (native) in the
fallback list
10:26 <ron> buxy: I'm not sure that really makes it better, it may just be wrong
for different (and maybe fewer) people ...
10:26 <buxy> ron: you would rather have it fail?
10:26 <ron> I do think I'd prefer it if the user had to be explicit about what
format they wanted, since I don't really have the sanity checks of
specifying -sX anymore to cross check that against ...
10:27 <ron> I think I'd rather have it fail at build time, than potentially make
and upload a "bogus" package yeah ...
10:28 <buxy> ron: well, the idea was to keep the same logic than with 1.0, if you
don't have any .orig, you fallback to the native mode
10:28 <buxy> I just generalized it a bit
10:28 <lifeless> buxy: that confuses very many people ;)
10:28 <ron> basically something like "format 1.0 assumed if no s/format exists or
--format specified, if illegal options for 1.0 are passed with no
format, bail out rather than trying to guess which format it may be"
10:29 <buxy> lifeless: at least now, dpkg-source explains its behaviour with
warnings
10:30 <ron> native should probably have to be forced. either with -sn or "3.0
(native)". that seems to be a common screw up even with the 1.0
format, so it would be nice to make that harder to happen rather than
easier
10:30 <lifeless> +1
10:31 <Clint> i think i agree
10:33 <buxy> ok, it deserves some discussion on -devel, but I'm not opposed to the
principle
--
Raphaël Hertzog
Reply to: