Ian Jackson writes:
> Russ Allbery writes:
>> Very belatedly, thank you, this makes a lot of sense. I hadn't thought
>> about the angle of the most likely vendor to be used in a
>> vendor-specific series file deciding whether they want this feature to
>> be used at all. When you point that out,
Russ Allbery writes ("Bug#850156: Please firmly deprecate vendor-specific
series files [and 1 more messages]"):
> Very belatedly, thank you, this makes a lot of sense. I hadn't thought
> about the angle of the most likely vendor to be used in a vendor-specific
> series fi
Guillem Jover writes:
> But for the Ubuntu case, which is what I was explicitly discussing with
> Steve, the reality is slightly different. The Ubuntu organization is
> reigned by their own rules, and it's a different entity to Debian, and
> how they reach their conclusions and policies is for th
Hi!
[
Had this sitting here half drafted, but as I got poked privately also
due to the apparent incoherence in the first part, I'm sending the
reply for that now. And will handle the other part later on.
Although, I guess, because it might be only partly on topic, I'm
considering whethe
Guillem Jover writes:
> If someone wants to see dpkg changed in some way related to this, I'd
> request the same thing I did to Ian a couple of years ago, gather input
> from derivatives and other current users, on their reasons for using it,
> or start a discussion with them on whether they'd be
On Tue, 2018-07-31 at 17:23:31 -0700, Steve Langasek wrote:
> On Wed, Aug 01, 2018 at 02:12:13AM +0200, Guillem Jover wrote:
> > I'm detaching dpkg from this, I don't see anything constructive to do
> > out if this, TBH.
>
> > If someone wants to see dpkg changed in some way related to this, I'd
>
On Wed, Aug 01, 2018 at 02:12:13AM +0200, Guillem Jover wrote:
> > 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 deprec
Processing control commands:
> reassign -1 debian-policy 3.9.8.0
Bug #850156 [dpkg-dev, debian-policy] Please firmly deprecate vendor-specific
series files
Bug reassigned from package 'dpkg-dev, debian-policy' to 'debian-policy'.
Ignoring request to alter found versions of bug #850156 to the same
Control: reassign -1 debian-policy 3.9.8.0
On Mon, 2018-07-30 at 06:15:42 +0200, Guillem Jover wrote:
> 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
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 wrot
On Wed, Apr 18, 2018 at 09:11:11PM -0700, Steve Langasek wrote:
> There isn't even a guarantee that what gets synced to Ubuntu has ever
> been unpacked - or *can* be unpacked - with dpkg-source.
Indeed. Not only is there no guarantee, but it goes wrong in practice
too.
As an operator of merges.u
On Wed, 18 Apr 2018 at 21:11:11 -0700, Steve Langasek wrote:
> The examples given are for series.ubuntu, which is certainly the case I've
> seen in the wild. Ubuntu, as a project, did not ask for this. As an Ubuntu
> developer, it has never benefitted me. I have only ever seen it used by
> Debia
On Thu, 19 Apr 2018 at 08:00:28 +, Mike Gabriel wrote:
> One example, where the vendor.series file is really helpful is:
> https://anonscm.debian.org/cgit/pkg-mate/mate-terminal.git/tree/debian/patches/2001_fix-find-next-previous.patch
That one-line change could easily be guarded by
#ifdef UBU
Hi,
On Do 19 Apr 2018 06:29:42 CEST, Steve Langasek wrote:
On Wed, Apr 18, 2018 at 02:36:14PM +0200, Mike Gabriel wrote:
> 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 diff
On Wed, Apr 18, 2018 at 02:36:14PM +0200, Mike Gabriel wrote:
> > 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
On Wed, Apr 18, 2018 at 09:15:25AM -0700, Sean Whitton wrote:
> Hello,
>
> 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 ?
> So
Hello,
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 ?
Sorry, I wrote my other e-mail before reading this.
ISTM that we can move towar
Hello Simon,
On Wed, Apr 18 2018, Simon McVittie wrote:
> Based on his work on dgit, I believe Ian considers the canonical
> contents of the source package to be the patches-applied
> state. Developers who agree with this point of view would say that
> applying patches is part of unpacking the so
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 + Ian Jackson
> > wrote:
> > > But [vendor.series] is quite wro
On Wed, 18 Apr 2018 at 14:36:14 +0200, Mike Gabriel wrote:
> On Wed, 4 Jan 2017 13:41:53 + Ian Jackson
> 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.
Hi,
On Fri, 6 Jan 2017 16:33:09 +0100 Andreas Henriksson
wrote:
> The vendor series files are mostly useless because most of the time you
> want /additional/ vendor patches, but the vendor series files completely
> replaces the original debian/patches/series which means you duplicate
> the ma
Hi Ian,
just got pointed by someone to this bug report.
On Wed, 4 Jan 2017 13:41:53 + Ian Jackson
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)' p
Hello.
On Wed, Jan 04, 2017 at 01:41:53PM +, Ian Jackson 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
On Wed, Jan 04, 2017 at 01:41:53PM +, Ian Jackson 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 o
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]
This feature is
25 matches
Mail list logo
