Bug#850156: Please firmly deprecate vendor-specific series files
Hi Ian,
just got pointed by someone to this bug report.
On Wed, 4 Jan 2017 13:41:53 +0000 Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Package: dpkg-dev, debian-policy
> Version: 1.17.27, 3.9.8.0
>
> dpkg-source has a surprising and not-very-well-documented feature,
> that it is possible to have in a `3.0 (quilt)' package a
> vendor-specific series file, which is used only if the vendor matches
> that of the running host.[1]
The under-documentation could be amended, then, I'd say.
> This feature is a very bad idea. I can see why people thought it
> might be nice: it means you can use the same (or very similar) .dsc
> (and perhaps vcs history) on different distros.
Disagreeing here...
The vendor.series file is a really helpful thing if you share packaging
workload with people from different Debian derivatives.
My main context when working for Debian derivates is: get everything
into Debian, bind the derivatives' devs' (wo)man(or other) power to
Debian and allow them to achieve their goals for their derivative distro
at the same time. Maintaining several slightly different src:package
versions in Debian and derivative X, Y and Z costs a lot of time.
The vendor.series file is a tiny helper tool, that eases people's day if
working in a context I described above.
With Ubuntu, where the vendor.series (i.e. ubuntu.series) file is used
here and there in my team contexts, you sometimes encounter Ubuntu
patches in third party package (which you don't have impact on) that
break a certain behaviour in a vanilla Debian package. Thus, having the
mechanism to easily patch the Ubuntu build of your package is very handy.
> But it 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)
> For example, if I am a Debian contributor and I download the Ubuntu
> version of the package and build it to see how it works, I actually
> get the Debian version. And vice versa.
Software in Ubuntu works different from software in Debian. Esp. in
pre-Ubuntu-GNOME times. E.g. the accountsserivce package contains so
many Ubuntu specific patches (they are reducing them, but still)... Many
packages from Ubuntu won't even work on Debian (e.g. the Ubuntu
Indicators stack). So, If you want to try how Ubuntu works, you are
likely forced to install Ubuntu. While this might not be needed for
basic tools, it certainly is the case for core Ubuntu packages (e.g.
packages related to Unity7, Ubuntu-GNOME, etc.). Packages in Ubuntu main
(vs. universe) are likely to fail on any other Linux OS (either at build
time or runtime).
> [...]
> * Warn that dpkg-source in buster will refuse to generate a `3.0
> (quilt)' source package containing non-default series files.
-1 from me.
> In policy:
>
> * Say that a package MUST NOT contain a non-default series file.
> (obviously with an expectation that these newly-declared RC bugs
> will not be fixed in stretch)
I am wondering, why you want a handy feature to be removed...
> [...]
> PS: Of course I have an angle. dgit depends on the assumption that a
> source package means a particular tree. This feature breaks that
> assumption, and as a result dgit must always fail on packages where
> this feature is in use.
Ah, here is the angle... Thanks for adding this PS. So we have "corner
case" against "corner case" (apologize my dgit
non-knowing-how-it-works-and-what-s-its-asset).
Thanks!
Mike
Reply to: