Hello,
On Fri 02 Apr 2021 at 10:22AM -07, Russ Allbery wrote:
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index a21a510..2fd6868 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -582,20 +582,17 @@ The three components here are:
>
> "Russ" == Russ Allbery writes:
Russ> Hi Sam,
Russ> Thanks for the review! There's now a newer version of this
Russ> diff adjusted for a flaw that Simon pointed out. It's
Russ> sufficiently different from the original diff that I don't
Russ> want to count seconds for
Sam Hartman writes:
>> "Russ" == Russ Allbery writes:
> Russ> Here is an updated diff that documents the most
> Russ> well-understood version conventions in the Debian archive.
> Russ> More could certainly be added; this is just a first start that
> Russ> addresses this
> "Russ" == Russ Allbery writes:
Russ> Here is an updated diff that documents the most
Russ> well-understood version conventions in the Debian archive.
Russ> More could certainly be added; this is just a first start that
Russ> addresses this specific bug.
Russ> This
On Fri, Apr 02, 2021 at 10:26:47AM -0700, Russ Allbery wrote:
> I'll therefore propose that we move the discussion of whether to give
> stronger advice on when to use native packages to a separate bug. Once
> this is merged, there will be some text in Policy defining native
> packages, so it will
Holger Levsen writes:
> I'm not sure if in this regard I would have liked the previous version
> better, as the paragraph about native packages is the only one which I
> would like to see extended to explain that it has been observed that
> packages we thought were native to Debian were not
Simon McVittie writes:
> The other way is to repackage the new upstream release from first
> principles, either because it's a new release from an upstream branch
> that's older than the one in testing/unstable (like src:flatpak in
> Debian 10), or because testing/unstable already has packaging
On Thu, 01 Apr 2021 at 18:17:59 -0700, Russ Allbery wrote:
> +- ``upstream_version`` components in native packages or
> + ``debian_revision`` components in non-native packages ending in
> + ``~debNuX`` also indicate a stable update, but of a different type.
> + This version convention indicates
Hi Russ,
On Thu, Apr 01, 2021 at 06:17:59PM -0700, Russ Allbery wrote:
> Here is an updated diff that documents the most well-understood version
> conventions in the Debian archive. More could certainly be added; this is
> just a first start that addresses this specific bug.
thank you for this,
Here is an updated diff that documents the most well-understood version
conventions in the Debian archive. More could certainly be added; this is
just a first start that addresses this specific bug.
This revised patch is less aggressive about defining native packages to
only mean packages with
Hello Russ,
On Sat, Jul 01, 2017 at 08:52:29AM -0700, Russ Allbery wrote:
> I thought there actually was a consensus that it's terrible. I certainly
> think it's not good practice. I would recommend against anyone doing
> this, speaking as someone who maintains lots of upstream software that I
On Sat, Jul 01, 2017 at 08:52:29AM -0700, Russ Allbery wrote:
[...maintaining non-Debian-specific software as a native package...]
> I certainly think it's not good practice.
I think it depends on the particulars of the situation.
I am upstream for two of the packages I maintain for Debian: nbd
On Sat, 01 Jul 2017 08:52:29 -0700, Russ Allbery wrote:
> Sean Whitton writes:
>
> > Some people frown upon this practice, but there are more than one of us
> > that do it, so probably worth mentioning in policy as a secondary use of
> > native packages (possibly a
Sean Whitton writes:
> Native packages are also used for software that is intended for use
> beyond Debian, but where the upstream maintainer also maintains the
> Debian package. In such cases, the Debian revision and orig tarballs
> represent needless overhead (tweaks
On Sat, Jul 01, 2017 at 04:46:21PM +0100, Adam D. Barratt wrote:
> fwiw, I can't think of situations where -deb9u1 would ever be used.
> Either a selected set of changes were applied to the package in stable,
> which would be +debXuY, or a newer upload was backported in its
> entirety, which would
On Sat, 2017-07-01 at 16:00 +0100, Sean Whitton wrote:
> On Sun, Jun 25, 2017 at 04:01:43PM -0700, Russ Allbery wrote:
> > > One rarer case is missing here:
> >
> > > 1.2.3-4~deb9u1
> > > Everything in 1.2.3-4 from unstable was in fact needed in Debian
> > > 9, so it was simply rebuilt for
On Sun, Jun 25, 2017 at 02:08:05PM -0700, Russ Allbery wrote:
> Concerns, objections, seconds?
Thank you for working on this.
> +A native package is software written specifically for Debian
> +whose canonical distribution format is as a Debian package.
> +Native packages have no
On Sun, Jun 25, 2017 at 04:01:43PM -0700, Russ Allbery wrote:
> > One rarer case is missing here:
>
> > 1.2.3-4~deb9u1
> > Everything in 1.2.3-4 from unstable was in fact needed in Debian
> > 9, so it was simply rebuilt for Debian 9 and uploaded there
> > (prominent examples:
On Sun, Jun 25, 2017 at 02:08:05PM -0700, Russ Allbery wrote:
> It's been a while since the last update to this thread and proposed
> wording about the special version numbering conventions in use in Debian,
> and in the meantime things have settled out a bit more and we have a
> pretty firm
Simon McVittie writes:
> On Sun, 25 Jun 2017 at 14:08:05 -0700, Russ Allbery wrote:
>> +upstream_version components in
>> +native packages ending in +nmu followed
>> +by a number indicate an NMU of a native package.
> I thought
It's been a while since the last update to this thread and proposed
wording about the special version numbering conventions in use in Debian,
and in the meantime things have settled out a bit more and we have a
pretty firm consensus on how to handle special versions. I'd therefore
like to
On Fri, 04 Sep 2009, Steve Langasek wrote:
I thought there had been one in the sarge timeframe; but I'm not going to go
digging any farther to confirm this. Yes, the problem is more or less
theoretical.
AFAIK, dak always refused uploads that would create such problems so
maintainers have to
On 05/09/09 at 14:26 +0200, Raphael Hertzog wrote:
On Fri, 04 Sep 2009, Steve Langasek wrote:
I thought there had been one in the sarge timeframe; but I'm not going to go
digging any farther to confirm this. Yes, the problem is more or less
theoretical.
AFAIK, dak always refused uploads
On Wed, Aug 26, 2009 at 11:29:57PM -0500, Manoj Srivastava wrote:
So, we should have:
,
| Format:
| Version:= [epoch`:']upstream_version[`-'debian_revision]
| Native Package NMU's:
| Version =~ m/\+nmu\d+$/
| Binary Only NMU's:
|Version =~ m/\+b\d+$/
`
On Tue, Sep 01, 2009 at 11:14:04PM +0200, Julien Cristau wrote:
On Tue, Sep 1, 2009 at 14:06:17 -0700, Steve Langasek wrote:
On Tue, Sep 01, 2009 at 11:39:40AM +0200, Julien Cristau wrote:
On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:
That's unfortunate. Imagine the
On 01/09/09 at 23:14 +0200, Julien Cristau wrote:
On Tue, Sep 1, 2009 at 14:06:17 -0700, Steve Langasek wrote:
On Tue, Sep 01, 2009 at 11:39:40AM +0200, Julien Cristau wrote:
On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:
That's unfortunate. Imagine the following
On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:
That's unfortunate. Imagine the following scenario:
1. Package P is released in sarge, with version 1.0-1.
2. Package P is installed on a system S, running sarge.
3. etch is released with P 1.0-1.
4. A security bug is found in P.
On Tue, Sep 01, 2009 at 11:39:40AM +0200, Julien Cristau wrote:
On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:
That's unfortunate. Imagine the following scenario:
1. Package P is released in sarge, with version 1.0-1.
2. Package P is installed on a system S, running sarge.
On Tue, Sep 1, 2009 at 14:06:17 -0700, Steve Langasek wrote:
On Tue, Sep 01, 2009 at 11:39:40AM +0200, Julien Cristau wrote:
On Sun, Aug 30, 2009 at 23:38:17 +0200, Lucas Nussbaum wrote:
That's unfortunate. Imagine the following scenario:
1. Package P is released in sarge, with
On 26/08/09 at 23:29 -0500, Manoj Srivastava wrote:
On Wed, Aug 26 2009, Steve Langasek wrote:
On Tue, Aug 18, 2009 at 04:25:37PM -0500, Manoj Srivastava wrote:
Given that devscripts, lintian, and the dev-ref
all advocate or implement +nmu\d+, and that debhelper and cdbs look
On Tue, Aug 18, 2009 at 04:25:37PM -0500, Manoj Srivastava wrote:
Given that devscripts, lintian, and the dev-ref
all advocate or implement +nmu\d+, and that debhelper and cdbs look
at the hyphen for determining native vs non-native, I have tried to do
so. I think the
On Wed, Aug 26 2009, Steve Langasek wrote:
On Tue, Aug 18, 2009 at 04:25:37PM -0500, Manoj Srivastava wrote:
Given that devscripts, lintian, and the dev-ref
all advocate or implement +nmu\d+, and that debhelper and cdbs look
at the hyphen for determining native vs non-native,
On Thu, Aug 20 2009, Steffen Joeris wrote:
I haven't followed all the discussion around this, so please excuse my
ignorance, but could someone try and explain to me in simple terms what we
are
trying to fix with all this policy stuff around versioning?
I don't see why we have to replace
On Tue, 18 Aug 2009, Manoj Srivastava wrote:
Additionally,
§ 5.6.21. `Files' mentions that the .dsc will contain a diff.gz if
applicable
§ C.1.1. `dpkg-source' states that it creates a diff.gz if
appropriate, and looks at the diff.gz while extracting if
On Wed, Aug 19 2009, Raphael Hertzog wrote:
On Tue, 18 Aug 2009, Manoj Srivastava wrote:
Additionally,
§ 5.6.21. `Files' mentions that the .dsc will contain a diff.gz if
applicable
§ C.1.1. `dpkg-source' states that it creates a diff.gz if
appropriate,
Hi
You can base security uploads on NMUs, so I think you could get
+deb50.1
+deb50.1+nmu1
+deb50.2
+deb50.2+nmu1
Hum I understand +nmu1+deb50.1 for a security upload of a package whose
last upload was an NMU, but I don't see in what occasions you would NMU a
package in
Package: debian-policy
Version: 3.8.3.0
Severity: wishlist
User: debian-pol...@packages.debian.org
Usertags: normative issue
Hi,
Currently, there is some ambiguity in the areas of version
numbering, debian_revision, native packages, and requirement for a
diff.gz/orig.tar.gz files in a
On Tue, 18 Aug 2009, Manoj Srivastava wrote:
Given these, I read this as letting the tools rely on
the following invariants, even though these are not explicitly spelled
out in so many words in policy:
1) If there is a - in the version number, then the package is
non-native
On Tue, Aug 18 2009, Don Armstrong wrote:
On Tue, 18 Aug 2009, Manoj Srivastava wrote:
Given these, I read this as letting the tools rely on
the following invariants, even though these are not explicitly spelled
out in so many words in policy:
1) If there is a - in the version
On Tue, Aug 18 2009, Don Armstrong wrote:
On Tue, 18 Aug 2009, Manoj Srivastava wrote:
Given these, I read this as letting the tools rely on
the following invariants, even though these are not explicitly spelled
out in so many words in policy:
1) If there is a - in the version
40 matches
Mail list logo