Bug#904302: Whether vendor-specific patch series should be permitted in the archive [and 1 more messages]
Adrian Bunk writes ("Bug#904302: Whether vendor-specific patch series should be permitted in the archive"):
> On Thu, Oct 04, 2018 at 08:21:07PM +0200, Philip Hands wrote:
> > IMO policy should recomend the use of separate source packages as the
> > prefered solution to the problem that vendor-specific patch series were
> > supposed to address.
>
> In this case please make an explicit decision on whether build-time
> patching is the recommended replacement for vendor-specific patch
> series, or what kinds of build-time patching will no longer be
> permitted.
Surely the TC can recommend X without outlawing Y.
> It is not clear at all which of the above exactly you want to have
> removed from the archive and moved as permanent deltas downstream.
Speaking personally, I think that packages should almost never look at
dpkg-vendor (or equivalent, eg looking at lsb_release). Any switching
on vendor is probably a bug. The reasons why switching on vendor is
probably wrong have been rehearsed earlier in this discussion.
But I am not asking the TC to outlaw the use of dpkg-vendor et al
because:
* The dpkg vendor series feature is uniquely weird and bad. (Both in
principle, and because of what are arguably lesser design bugs.)
* Unlike the dpkg vendor series feature, the use of dpkg-vendor (or
equivalent) at build- or run-time is not directly in the way of my
project to improve our source code management processes.
* I think an effort to outlaw switching based on vendor would
generate a much bigger fight which is not worth having.
* I hope that my programme of making it easier to handle divergence
properly, by having actually different source code, and carrying
that delta indefinitely, will tempt people away from these kind of
vendor-switching approaches.
Another way to look at this is that in general, where possible, I
think transitions to new things should be done by making the new thing
attractive rather than by going around forbidding or breaking the old
thing.
Sadly the vendor series feature is too broken, and causes too many
problems for others, for that. The problems of switching on vendor
are real but much less severe so taking the carrot rather than stick
approach is much more sensible.
But of course a body like the TC should certainly recommend good
practices rather than troublesome ones.
> The TC was asked to make a decision, and a decision turning a clear
> situation into a blurry "it is permitted but kinda recommended against"
> would only create future conflicts.
We have a lot of things in Debian where one approach is recommended,
but other approaches are permitted or tolerated. This does not in
general seem to result in conflicts.
> A 1:1 vendor-specific patch series -> build-time patching change
> would be a mostly technical change. As already said this could
> even be implemented before buster.
Because I think dpkg-vendor is the wrong answer, I don't want the TC
to recommend that.
Philip Hands writes ("Bug#904302: Whether vendor-specific patch series should be permitted in the archive"):
> However if someone reads the prohibition against vendor-specific patch
> series, and is left wondering what is the best way to deal with this
> situation, then it would probably be helpful to give them a hint.
Quite.
Ian.
Reply to: