Bug#850156: Please firmly deprecate vendor-specific series files [and 1 more messages]
On Wed, 2018-04-18 at 09:15:25 -0700, Sean Whitton wrote:
> On Wed, Apr 18 2018, Ian Jackson wrote:
> > FAOD I feel very strongly about this. The bug is over a year old.
> > Can the Policy Editors please tell me when it would be apprropiate to
> > escalate this to the TC ?
*Sigh*
> Sorry, I wrote my other e-mail before reading this.
>
> ISTM that we can move towards consensus on this bug by developing
> tooling that allows downstreams to make better use of dgit. That is, we
> offer them something that does the work that vendor-specific series
> files are doing.
>
> We are actively working on the relevant processes and tools right now.
> Let's see what things look like once we reach the end of that work
> before escalating this bug anywhere.
[ Well, apparently not, because it was referred to the ctte anyway…
I had pending a reply to this thread, but when I saw your mail
I thought this was going to be solved properly by technical means,
and deprioritized it, should have known better I guess. It seems
we are going through the hammer of authority yet again. ]
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.
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…
Thanks,
Guillem
Reply to: