Bug#850156: Please firmly deprecate vendor-specific series files [and 1 more messages]
Simon McVittie writes ("Bug#850156: Please firmly deprecate vendor-specific series files"):
> On Wed, 18 Apr 2018 at 14:36:14 +0200, Mike Gabriel wrote:
> > On Wed, 4 Jan 2017 13:41:53 +0000 Ian Jackson
> > <ijackson@chiark.greenend.org.uk> wrote:
> > > But [vendor.series] is quite wrong, because it means that the same
> > > source package has different "contents" on different computers.
> >
> > The source package is always the same. The bin:pkgs' contents is different.
> > But that is different anyway, even if built against different versions of
> > Debian. You have to rebuild the package for your system anyway, so what is
> > your point here? (addressing Ian with this question)
By `"contents"' I meant "what you get if you say dpkg-source -x".
So my complaint is that saying `dpkg-source -x' produces a different
source tree on different systems. I find it difficult to see how it
is not obvious that this is very undesirable.
As an example of what can go wrong:
-*- alice has joined #gnomovision -*-
<alice> Hi. I'm using jessie. Does anyone know if jessie's
gnomovision has compatibility with elves ?
bob@ubuntu$ dget packages.debian.org/.../gnomovision_1.2-3.dsc
... blah blah debian/series.ubuntu ...
... blah blah debian/patches/elf.patch ...
bob@ubuntu$ dpkg-source -x gnomovision_1.2-3.dsc
bob@ubuntu$ grep -li elves gnomovision-1.2/src/*.c
gnomovision-1.2/src/creatures.c: void handle_elven_mithril(...) {
etc etc. etc.
<bob> I just UTSL and sure, it looks like though they have 1.2,
they have applied the patch from the Elf support team.
But of course it turns out that the elf patch is in series.ubuntu for
some reason. bob has misinformed alice. But he made only reasonable
assumptions.
Another scenario:
<alice> My buster system is affected by #801234 which is
very annoying. Any tips ?
<carol> Hrm, I had a look and AFAICT from https://launchpad//
this is fixed in the Ubuntu version of the package.
<carol> The bug reports are all a bit confusing though.
I suggest you try just building the Ubuntu version of the
package and see if it fixes it. If it does maybe we can
send the patch to the Debian BTS.
<alice> I can try that easily enough. Let me see...
alice@buster$ dget archive.ubuntu.com/.../gnomovision-1.7-4ubuntu3.dsc
alice@buster$ dpkg source -x gnomovision-1.7-4ubuntu3.dsc
alice@buster$ cd gnomovision-1.7
alice@buster$ dpkg-buildpackage -uc -b
alice@buster$ dpkg -iGROEB ../*.deb
dpkg: installing gnomovision_1.7-4ubunut3_riscv.deb
alice@buster$ gnomovision --whatever-it-is
[ exhibits #801234 ]
<alice> Hrm, no, I tried 1.7-4ubuntu3 and it has the bug too.
<carol> Weird. The bug is closed in Launchpad. That's
probably a mistake.
<alice> I guess I will reopen it there then. Thanks.
(later)
From: gnomovision maintainer in Debian and Ubuntu
To: alice
Subject: gnomovision and LP:...
Why did you reopen this bug? The bug *is* fixed in Ubuntu,
in debian/patches/unmangle-wurzels.patch.
Your transcript seems to show you building the package on Debian.
Building on Debian is not supported by Ubuntu. And in fact this
bugfix is not applied on Debian because it is in the series.ubuntu
file.
This is because the Debian gnomovision-gui maintainer objected to
the way the patch changed the stdout texts, so I made the patch
apply only on Ubuntu (where it is more important to fix this bug
than to support gnomovision-ui, which is in universe).
<alice> carol: Thanks for your tips about #801234 and Ubuntu.
<alice> You would not believe what I discovered about gnomovision's
Ubuntu package, and dpkg-source...
> Based on his work on dgit, I believe Ian considers the canonical
> contents of the source package to be the patches-applied state.
It's not about arbitrary abstract definitions of canonical. It's
about what someone ends up grepping, and editing, and, ultimately,
compiling.
Not everyone who uses .dsc packages knows all about this stuff. Nor
should they have to.
On Fri, 6 Jan 2017 16:33:09 +0100 Andreas Henriksson <andreas@fatal.se>
wrote:
> Thus, even if you deprecate vendor series files that will make little
> practical difference. I don't see the point. The only thing you'll
> accomplish is to make it a bit harder for different vendors to
> collaborate on the same source in Debian rather than downstreams
> carrying their own delta and we stick our head in the sand on the debian
> side and pretend it doesn't exist.
Having the same .dsc unpack to different files on different systems
has a whole host of practical problems.
People unpack source code for other reasons than building it.
*One* of the problems is that it makes dgit literally impossible.
I have in fact had to write a countermeasure, which is that if you try
to dgit clone a package with a series.ubuntu on an ubuntu system, it
will bomb out. (FAVO "ubuntu".)
> > In practise what instead happens is that debian/rules gets hacked to
> > query dpkg-vendor (or $(DEB_VENDOR)) and apply the extra patches or do
> > derivate/vendor specific things to the package.
> > If you go looking in the archive you'll find that this is likely much
> > more common than the few examples you've found that uses the vendor
> > specific series.
>
> Oh, yeah. Seen that, too. This makes debian/rules file really awful.
> Esp. when quilt patching and debian/rules patching gets combined.
I think this is bad practice too, just not as bad as vendor patches.
Much better is to actually edit the source code and have two different
packages when the packages are supposed to be different!
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 ?
Ian.
--
Ian Jackson <ijackson@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.
Reply to: