Control: reassign -1 debian-policy 3.9.8.0 On Mon, 2018-07-30 at 06:15:42 +0200, Guillem Jover wrote: > In any case, I discussed this in a private mail interchange with Ian > a couple of years ago (AFAIR). My reply back then was that I don't > personally feel very strongly about the feature, that I think it has > some merit and that before even considering any kind of deprecation > I'd like to get input from derivative developers (Ubuntu is obviously > not the only derivative) and other people using it for their rationale, > etc. > > Personally I do have a preference for doing unconditional patching, > that ideally does feature selection at configure/build/run-time. But I > don't think this is generally applicable to all programming languages > or environments, which might not have the notion of some meta language > or preprocessor, or might not be able to portably select OS and then > a vendor and similar. At least w/o creating a huge mess of code. > > Also if any potential deprecation might imply that people will switch > from declarative to vendor-conditionalized patching from within > debian/rules, well, that looks like a regression to me.
In addition, there's the confounding of the source package as a transport format, with the tools used to extract them, the process to do so, and the end result on disk. The vendor-specific series can be thought of just as a serialization of multiple branches. How this ends up being unpacked could vary, the unpacker could generate say a git repo, and create multiple branches, and point HEAD to the current vendor. This is a tooling behavior issue. If this is really causing problems to dgit, then it feels to me like a self-inflicted consequence of its design. > I'm definitely not even going to consider removal of extraction support, > because that would break at least historic source unpacking. That's > the price of adding these kinds of features into dpkg. > > When it comes to deprecation of the packing, see above. When I saw this > thread I initially though that at least adding options to forbid packing > and unpacking this kind of source would be a nice compromise, but with > the ctte being involved I've lost any motivation for that. > In any case I'm not even sure why dpkg is any kind of blocker for this > at all, because acceptance into the Debian archive is controlled by > ftp-masters, f.ex via lintian and its auto-reject list. Well, it might > be if there's some kind of intention to try to block this even for other > unrelated derivatives… I'm detaching dpkg from this, I don't see anything constructive to do out if this, TBH. If someone wants to see dpkg changed in some way related to this, I'd request the same thing I did to Ian a couple of years ago, gather input from derivatives and other current users, on their reasons for using it, or start a discussion with them on whether they'd be satisfied with potential alternatives, etc. Thanks, Guillem
