[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#904302: marked as done (Whether vendor-specific patch series should be permitted in the archive)

Your message dated Tue, 13 Nov 2018 19:12:53 +0100
with message-id <87tvkk7snu.fsf@err.no>
and subject line Re: Bug#904302: Call for vote on disallowing the use dpkg's vendor series in the archive
has caused the Debian Bug report #904302,
regarding Whether vendor-specific patch series should be permitted in the archive
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
904302: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904302
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: tech-ctte
X-debbugs-cc: debian-policy@lists.debian.org, sunweaver@debian.org, ijackson@chiark.greenend.org.uk, smcv@debian.org, vorlon@debian.org
Control: block 850156 by -1

As a Debian Policy delegate I hereby request that the Technical
Committee decide whether a proposal that has been submitted to modify
the Debian Policy Manual should be accepted:

    #850156 [n|  |  ] [dpkg-dev, debian-policy] Please firmly deprecate vendor-specific series files

I am making this request because we have not been able to establish
consensus, but I think this bug is one that we should not just leave
sitting open against debian-policy: if the proposal is eventually
accepted, then leaving the bug open means more vendor-specific series
files in the archive that then have to be removed.

There are currently at least 18 source packages which use
vendor-specific series files.  I have not been able to determine an
upper bound.

Before continuing to summarise the issue, I should state a conflict of
interest.  I am one of the people working on dgit, and Ian Jackson's
motivation for proposing this change is because packages with
vendor-specific series files cannot be used with dgit.  I share Ian's
desire to make dgit work with as many packages as possible, and this
might have biased the following summary.  I am, however, confident in my
judgement that this proposal should be brought before the committee.

Vendor-specific patch series are a feature of dpkg that can be used to
apply a different series of quilt patches when the source package is
unpacked on different systems.  So for example, there could be an Ubuntu
patch series alongside the default patch series, and then the results of

    % dpkg-source -x foo.dsc

would be different depending on whether you are running Ubuntu or
another system (e.g. Debian).

Source packages are intended as a compressed representation of unpacked
source packages, for transportation.  But thanks to vendor-specific
patch series, it is not the case that the composition of packing and
unpacking a source package is guaranteed to be the identity function.[1]
This is very odd for a transportation format.

The practical consequences fall into two categories.  Firstly, it makes
it difficult to develop tools like dgit, which must assume that the
compressed representation works like other compressed representations.
And secondly, it can be quite confusing to users working with the
compressed representation directly.  These practical consequences are
the reasons why I think we should get this bug

For example, someone might want to use a Debian system to investigate a
bug on an Ubuntu system.  They might begin by downloading some source
packages from the Ubuntu mirrors.  Since they obtained them from Ubuntu,
they will form the reasonable expectation that unpacking these source
packages will get them the code running on the Ubuntu system they are
debugging.  But if the source packages use vendor-specific patch series,
they might get something quite different -- which, until they realise,
might completely block them from resolving the bug.  As Ian puts it,
"The version of the package you get should depend on where you got the
package from, not where you are looking at it."

On the other hand, Mike Gabriel objects to the removal of
vendor-specific patch series because they are a way of reducing the
maintainance burden for packages that need to be slightly different in
Debian and in derivatives like Ubuntu:

> 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.

A concrete example from Mike: https://bugs.debian.org/850156#60

It has been argued that vendor series are simply a more convenient way
of doing the equivalent of "#ifdef ubuntu".  Ian and I don't agree.
#ifdefs are visible in the actual source code, where users will look to
understand the behaviour.  Doing this kind of work in the source code or
the build system is much more conventional, than doing it in the source
code delivery mechanism.  In particular, it doesn't violate the
idempotency of packing and unpacking the source package.  #ifdefs like
this do not cause any trouble for tools like dgit.

A final argument in favour of Ian's proposal that seems worth including
here, from Steve Langasek:[2] vendor-specific patch series arguably
represent the improper upstreaming of derivative modifications into
Debian.  Instead of modifying the patch such that it can be incorporated
into the Debian patch series (or even the software's next upstream
release), it is "merged" into the Debian .dsc by copying it into a
vendor-specific series file.  Either patches are properly upstreamable,
or they are Ubuntu-specific modifications that should never make it into
the Debian archive at all; vendor-specific patch series represent an
unhelpful middle ground.

The concrete question that I am asking the committee to decide, in my
capacity as a Policy delegate, is whether or not vendor-specific patch
series should be permitted in the Debian archive.

There is a broader question of whether source packages should be allowed
to unpack differently on different systems through other means, such as
patch systems implemented in debian/rules (this could be done using
dpkg-vendor(1)).  But given that 3.0 (quilt) is now dominant, you might
leave this broader question aside.

[1]  There are other reasons why this is not the identity function for a
     lot of our source packages, but these are much more subtle and not
     a matter of the system on which the source package is unpacked, so
     I suggest leaving those aside for this bug.

[2]  https://bugs.debian.org/850156#55

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- 
]] Tollef Fog Heen 

> A: Approve resolution, disallowing the use of dpkg's vendor series
> F: Further Discussion

With five votes in favour and none against, the resolution passes.

I'll post to d-d-a.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

--- End Message ---
Reply to: