> Running dpkg-source -x on a source package MUST produce the source
> of the package, ready for editing, and allow one to make changes,
The "ready for editing" language is a bit too sloppy for Policy. Ultimately
all packages are 'ready for editing' once unpacked, it's just that you might
be surprised by what you have to edit.
Does 'ready for editing' mean it has to be patches-applied when unpacked?
Does that accidentally forbid tarball-within-tarball packages? (Do we have
any of them still or have they finally all disappeared?)
> and run dpkg-buildpackage to produce a modified package, without
> taking any additional steps.
"run dpkg-buildpackage to produce a modified package" is also too loose.
Does that mean source package or binary package? If it means binary package,
then almost every package is non-compliant with that as a local change would
cause dpkg-buildpackage to fail with:
dpkg-source: info: local changes detected
... of the 3.0 (quilt) source format packages, the only compliant ones would
have "auto-commit" in debian/source/options of which there are a total of 5
in the archive.
>> Previously, packages which had ad-hoc patch systems would document
>> their source code management practices in debian/README.source.
>> Source packages now MUST NOT use in-source-package patch systems
>> other than `3.0 (quilt)'.
>
> How many packages in the archive would we make buggy by adding this
> requirement?
A starting point would be "every package that build-depends on quilt or
dpatch" of which there are 868.¹ There are 155 packages that are using some
other patch system such as provided by CDBS.²
Since the 'patch' package is within the build-essential set, it's not easy
to know what packages are using patch(1). There are 1159 packages that talk
about patching things in debian/rules³ some of which are build-time commands
and some of which are only helpers for the maintainer or comments. There are
quite a few cases where arch-specific patches exist -- 3.0 (quilt) doesn't
provide for arch-specific patches. I'm assuming that the proposal is not to
drop all archs that need arch-specific patches ;) There are also build-
stage-specific patches for bootstrapping.
There are also plenty of packages that do a little sed magic in d/rules to
alter some source prior to building. Sometimes that could be expressed as a
patch but that patch can be very fragile (needing to be re-made on every
single new upstream release) while the sed is not. Fiddling thing with sed
sounds a lot like an ad hoc patch system to me and is certainly not
something that should be forbidden.
There are a lot of packages in these lists that are maintained by
experienced maintainers who selected these approaches for sensible technical
reasons. Some (like simple-patchsys.mk) are relics but most are not. I think
we're a long way from a "MUST NOT" on this sort of thing. Given the way
packages like gcc-*, pythonX.Y and linux are operating (and many others
besides) are operating, there needs to be an alternative that the
maintainers consider viable first, and then a migration to that alternative.
A couple of additional points:
* Deprecating patch systems should also deprecate the 'patch' target in
debian/rules from §4.9.
* There are still other useful roles for d/README.source documented within
policy and in associated documents; the python modules team refer to
README.source as the place to document that a package is not using their
standardised tool (git-dpm) and why, for instance.
cheers
Stuart
¹ build-rdeps quilt = 760; build-rdeps dpatch = 108
² https://lintian.debian.org/tags/debian-rules-uses-deprecated-makefile.html
³ https://codesearch.debian.net/search?q=path%3Adebian%2Frules+patch
--
Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
