The policy section "Source package handling: debian/README.source"
should be entirely replaced with a requirement that

  Running dpkg-source -x on a source package MUST produce the source
  of the package, ready for editing, and allow one to make changes,
  and run dpkg-buildpackage to produce a modified package, without
  taking any additional steps.

  If the upstream or Debian source code maintenance practices applying
  to the package are nontrivial (for example, if the uploaded source
  package is itself generated from a metarepository), this should be
  documented in debian/README.source.

And one could probably add

  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)'.

Ian.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

How many packages in the archive would we make buggy by adding this
requirement?  I think it's probably the right thing to do anyway, but I'd
like to understand the scope of the disruption.

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?)

"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.

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

Ian, do you have an updated proposal in response to Stuart's points?

Thanks for noting this.

Agreed, but we probably don't need to list all those roles in policy.

Hi!

Now that #850156 (deprecate vendor-specific series files) is resolved, we have
a recommended pathway by which maintainers can stop using debian/vendor.series
files. Amongst other alternatves, the technical committee resolution advised
maintainers to use systems that apply patches at build time:

" … or as part of the build process using current and future practices such as
patches with conditional behaviour or patching of files during the build
rather than at source unpacking time." (#904302)

It is thus inappropriate to deprecate ad hoc patch systems in Policy, since
that is what has been recommended in the CTTE resolution. Moreover, since the
reporter of this bug #850157 (deprecate ad hoc patch systems) agreed with the
wording of this CTTE resolution, I assume that this discussion is now
obsoleted by later events.

I believe that #850157 can be closed.

Cheers
Stuart

Stuart Prescott writes ("Bug#850157: Please deprecate all ad-hoc patch systems"):

Firstly:

The thing #850157 is about is systems where patches are
unconditionally applied (sometimes, in large numbers).
simple-patchsys.mk, and various ad hoc schemes.  debian/rules patch
targets, and so forth.

These uses have basically all been obsoleted by `3.0 (quilt)'.  While
I think `3.0 (quilt)' has significant problems, it is certainly better
than all those things that went before.

I think that, nowadays, no package should use an ad-hoc patch system
for situations where `3.0 (quilt)' (possibly with multiple orig
tarballs) would suffice.  IMO that should be clearly stated in policy.

TBH by now I expect this should be reasonably uncontroversial.

I think this probably covers all situations where the
`debian/rules patch' target is applicable, so that should probably be
deprecated too.  But I could be wrong about that.

If we worry about the impact of making this rule RC (because of the
presence of source packages using ad-hoc, hairy and superseded source
code management techniques) we should at least make it a SHOULD - and
have a lintian warning for the easy-to-spot cases.


Earlier, Stuart, you wrote:

So, to clarify, I don't want to try to deprecate those.

I do think that there are some situations where build-time patching is
a necessary evil.  I definitely wouldn't want to forbid it entirely.

Personally I think a SHOULD NOT might be appropriate for all kinds of
build-time patching, but it doesn't seem to me that many maintainers
would gratuitously deploy build-time patching.  The downsides of such
approaches are fairly obvious, and while they are felt more keenly by
people other than the maintainer, the maintainer is also paying a
price.

So I don't mean by this bug report to request that all build-time
patching should be deprecated.


Secondly:

It's true that the TC resolution clearly states that conditional
patching at build-time is tolerable.

But, the committee did not conduct a thorough analysis of the
alternatives, and carefully avoided expressing a clear view on what
should be done instead.  I don't think you can infer from the fact
that something appears at the end of a list of suggestions starting
"current and future practices such as ..." that the TC are actually in
favour of it.

And the TC did not express a view on, say, the rules patch target.


Thirdly:

Specifically, the TC resolution *does not* explicitly suggest
conditional patching based on dpkg-vendor.  It merely suggests
conditional patching in the abstract, and the reader is left to decide
what the appropriate condition is.

As I said in the TC discussion for #904302 I am definitely not a fan
of conditional patching based on dpkg-vendor.  I think conditional
patching based on dpkg-vendor is nearly always wrong.

I didn't push harder for forbidding the use of dpkg-vendor, #ifdef
ubuntu, etc., for a number of reasons which are as much social as
political.  The harm done by these kind of strategies is real but the
cost of educating everyone, let alone fighting over it, would be
disproportionate.


Thanks,
Ian.