Stuart Prescott writes ("Bug#850157: Please deprecate all ad-hoc patch
systems"):
> 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.
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:
> There are a lot of packages in these lists that are maintained by
> experienced maintainers who selected these approaches for sensible
> technical
> reasons.
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.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
