Your message dated Tue, 13 Nov 2018 19:12:53 +0100 with message-id <87tvkk7snu....@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 ow...@bugs.debian.org immediately.) -- 904302: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904302 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: tech-ctte X-debbugs-cc: debian-pol...@lists.debian.org, sunwea...@debian.org, ijack...@chiark.greenend.org.uk, s...@debian.org, vor...@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
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 ---
