Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[Russ Allbery]

Joey Hess <[EMAIL PROTECTED]> writes:

> (For the second time, please preserve my CC.)

> Bart Martens wrote:

>> Yes, lintian.  Two examples where lintian seems to follow/accept the
>> numbering described in developer's reference:

>> Example one: Try doing an NMU of dh-make-php with adding ".0.1".  Then
>> lintian produces this warning:
>> W: dh-make-php source: source-nmu-has-incorrect-version-number 0.2.3.0.1

> I don't think lintian counts as something that is broken by this. Old
> versions of lintian didn't include this check, since the developer's
> reference didn't specify the broken version numbers.

I'm happy to change this if need be.

> Also, lintian's NMU handling code is broken in plenty of other ways. For
> example, it relies heiristically on a given set of phrases in the
> changelog to indicate an NMU.

That's not really what it's doing, although some of the tags are written
to imply that.  It's checking the convention in DevRef 5.11.3.  That's
independent of how it determines whether a package is an NMU.

lintian determines whether a package is an NMU by checking the last
changelog signature against Maintainers and Uploaders.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[Joey Hess]

[EMAIL PROTECTED] wrote:
> Because it may be more important to be able to identify an NMU from the
> version number than to be able to identify a native package from the
> version number...

I don't see why it's important to be able to tell that from a version
number at all. It's also not the rationalle that lintian gives:

N:   A source NMU should have a Debian revision of '-x.x'. This is to
N:   prevent stealing version numbers from the maintainer (and the -x.x.x
N:   version numbers are reserved for binary-only NMU's).

But there are plenty of other ways to avoid "stealing" native version
numbers. There are also plenty of ways to make it clear that a native
version number has been NMUed, without breaking the native if ! /-/ check.

> > The developer's reference chose to ignore or change a longstanding practice
> > of never using debian revision numbers in native packages. Changing this
> > breaks software that has relied on this practice for ten or more years.
> > Not just debhelper, but debstd and cdbs, and who knows what else.
> 
> How does it break them?

As documented in #437392, particularly, files whose location differs between
native and non-native packages are renamed when the package is NMUed.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#437392: Info received and FILED only (was Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this problem report.  It has NOT been forwarded to the package
maintainers, but will accompany the original report in the Bug
tracking system.  Please ensure that you yourself have sent a copy of
the additional information to any relevant developers or mailing lists.

If you wish to continue to submit further information on this problem,
please send it to [EMAIL PROTECTED], as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[Joey Hess]

Julien Cristau wrote:
> It also implies that if there is no debian_revision, upstream_version
> can contain a hyphen.

Utterly false:

  The  may contain only alphanumerics[1] and the
  characters `.'  `+' `-' `:' (full stop, plus, hyphen, colon) and
  should start with a digit.  If there is no  then
  hyphens are not allowed; if there is no  then colons are
  not allowed.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[Joey Hess]

(For the second time, please preserve my CC.)

Bart Martens wrote:
> Yes, lintian.  Two examples where lintian seems to follow/accept the
> numbering described in developer's reference:
> 
> Example one: Try doing an NMU of dh-make-php with adding ".0.1".  Then
> lintian produces this warning:
> W: dh-make-php source: source-nmu-has-incorrect-version-number 0.2.3.0.1

I don't think lintian counts as something that is broken by this. Old
versions of lintian didn't include this check, since the developer's
reference didn't specify the broken version numbers.

Also, lintian's NMU handling code is broken in plenty of other ways. For
example, it relies heiristically on a given set of phrases in the
changelog to indicate an NMU.

Any better examples?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[luk]

On Tue, Aug 14, 2007 at 01:38:04PM -0400, Joey Hess wrote:
> Bart Martens wrote:

> > Policy does not explicitly state that the presence/absence of a
> > "debian_revision" or that the presence/absence of hyphen(s) "-" indicate
> > whether or not the package is a "native Debian package".
> 
>  
> 
>   It is optional; if it isn't present then the 
>   may not contain a hyphen.  This format represents the case where
>   a piece of software was written specifically to be turned into a
>   Debian package, and so there is only one "debianisation" of it
>   and therefore no revision indication is required.
> 
> This strongly implies that debian native packages don't use debian_revision.

That's why it is in the normal case.

> > > I don't know why the
> > > developers reference choses to ignore that. 

Because it may be more important to be able to identify an NMU from the
version number than to be able to identify a native package from the
version number...

> > Policy and developer's reference do not contradict explicitly on the
> > version numbering of an NMU of a native package.
> 
> The developer's reference chose to ignore or change a longstanding practice
> of never using debian revision numbers in native packages. Changing this
> breaks software that has relied on this practice for ten or more years.
> Not just debhelper, but debstd and cdbs, and who knows what else.

How does it break them?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[Julien Cristau]

On Tue, Aug 14, 2007 at 19:45:11 +0200, Julien Cristau wrote:

> It also implies that if there is no debian_revision, upstream_version
> can contain a hyphen.
> 
No it doesn't.  Sorry about that...

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[Julien Cristau]

On Tue, Aug 14, 2007 at 13:38:04 -0400, Joey Hess wrote:

> Bart Martens wrote:
> > Policy states that if there is no "debian_revision" then hyphens "-" are
> > not allowed in the "upstream_version".
> > http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
> > Policy also states that "native Debian packages" are "packages which
> > have been written especially for Debian".
> > http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1
> > 
> > Policy does not explicitly state that the presence/absence of a
> > "debian_revision" or that the presence/absence of hyphen(s) "-" indicate
> > whether or not the package is a "native Debian package".
> 
>  
> 
>   It is optional; if it isn't present then the 
>   may not contain a hyphen.  This format represents the case where
>   a piece of software was written specifically to be turned into a
>   Debian package, and so there is only one "debianisation" of it
>   and therefore no revision indication is required.
> 
> This strongly implies that debian native packages don't use debian_revision.
> 
It also implies that if there is no debian_revision, upstream_version
can contain a hyphen.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[Joey Hess]

(Please keep debian-devel in the CC. This issue is a project-wide
isssue.)

Bart Martens wrote:
> How do other tools this?

Other well-respected tools in debhelper's situation, such as?

yada
It introduces a completely nonstandard Upstream-Source field in
debian/control which it takes to mean the package is not native.

debstd
Same as debhelper.

cdbs
Same as debhelper.

Manoj's standardised rules files
Same as debhelper.

> > I can think
> > of a few ways, but they're all fairly complicated and fragile.
> 
> Maybe verifying the presence of an .orig.tar.gz ?

Complicated, fragile, out of scope for debhelper, which does not deal
with debian source packages after all, breaks once wig-n-pen is implemented.

> > Policy is actually careful to set up the invarient that "-" anywhere in
> > a version number means the package is not native. 
> 
> Policy states that if there is no "debian_revision" then hyphens "-" are
> not allowed in the "upstream_version".
> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
> Policy also states that "native Debian packages" are "packages which
> have been written especially for Debian".
> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1
> 
> Policy does not explicitly state that the presence/absence of a
> "debian_revision" or that the presence/absence of hyphen(s) "-" indicate
> whether or not the package is a "native Debian package".

 

  It is optional; if it isn't present then the 
  may not contain a hyphen.  This format represents the case where
  a piece of software was written specifically to be turned into a
  Debian package, and so there is only one "debianisation" of it
  and therefore no revision indication is required.

This strongly implies that debian native packages don't use debian_revision.

> > I don't know why the
> > developers reference choses to ignore that. 
> 
> Policy and developer's reference do not contradict explicitly on the
> version numbering of an NMU of a native package.

The developer's reference chose to ignore or change a longstanding practice
of never using debian revision numbers in native packages. Changing this
breaks software that has relied on this practice for ten or more years.
Not just debhelper, but debstd and cdbs, and who knows what else.
 
> Interesting idea, but it does not conform to current po^H^Hdeveloper's
> reference,

Please stop trying to conflate policy and the developer's reference. The
developers reference is not something one conforms to, it is something one
refers to.

> and changing this now probably breaks existing software
> depending on the current version numbering of NMU's of native packages.

Well, I've identifes several more pieces of software that are broken by
the syntax introduced by the developer's reference. Can you identify at
least *1* that would be broken by not following it? Bear in mind that
appending "0.0.0.1" or similar is a de-facto standard that is what most
people did for many years when NMUing native packages.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[Julian Andres Klode]

Am Montag, den 13.08.2007, 22:26 +0200 schrieb Julian Andres Klode:
> Am Montag, den 13.08.2007, 15:50 -0400 schrieb Joey Hess:
> 
> > Policy is actually careful to set up the invarient that "-" anywhere in
> > a version number means the package is not native. I don't know why the
> > developers reference choses to ignore that. Is there something wrong
> > with using a version number like "1.0.0.1" for native package NMUs?
> > (Being careful to choose one that is well outside the normal range.
> > "1.0.debian.1" if necessary.)
> > 
> I suggest to use nmu, like 1.0nmu1.
> 
> Some people use version like "1.0.0.1" for NMUs of binary packages.
s/binary/native
-- 
Julian Andres Klode

IRC Nickname:   juliank (Debian/OFTC + Freenode, GimpNet)
Fellow of FSFE: https://www.fsfe.org/en/fellows/jak (No. 1049)
Debian Wiki:http://wiki.debian.org/JulianAndresKlode
Ubuntu Wiki:http://wiki.ubuntu.com/JulianAndresKlode
In Launchpad:   https://launchpad.net/~juliank
My packages:  http://qa.debian.org/[EMAIL PROTECTED]
Languages:  German, English, [bit French]


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[Julian Andres Klode]

Am Montag, den 13.08.2007, 15:50 -0400 schrieb Joey Hess:

> Policy is actually careful to set up the invarient that "-" anywhere in
> a version number means the package is not native. I don't know why the
> developers reference choses to ignore that. Is there something wrong
> with using a version number like "1.0.0.1" for native package NMUs?
> (Being careful to choose one that is well outside the normal range.
> "1.0.debian.1" if necessary.)
> 
I suggest to use nmu, like 1.0nmu1.

Some people use version like "1.0.0.1" for NMUs of binary packages.
-- 
Julian Andres Klode

IRC Nickname:   juliank (Debian/OFTC + Freenode, GimpNet)
Fellow of FSFE: https://www.fsfe.org/en/fellows/jak (No. 1049)
Debian Wiki:http://wiki.debian.org/JulianAndresKlode
Ubuntu Wiki:http://wiki.ubuntu.com/JulianAndresKlode
In Launchpad:   https://launchpad.net/~juliank
My packages:  http://qa.debian.org/[EMAIL PROTECTED]
Languages:  German, English, [bit French]


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Bug#437392: debhelper: subroutine "isnative" in Dh_Lib.pm is confused by NMU of native package

[Joey Hess]

Bart Martens wrote:
> Now imagine that someone would do an NMU of dh-make-php.  The right
> version would be 0.2.3-0.1 according to Debian Policy.

Actually, policy doesn't say any such thing. That syntax was invented by
the developer's reference. And it's IMHO dubious. 

Consider two packages:

foo is native and at version 1.0
bar is at version 0.9-1

Now, NMU foo to fix a bug, and NMU bar, upgrading it to version 1.0. If
you follow the developer's reference, you get:

foo is "native" at version 1.0-0.1
bar is at version 1.0-0.1

Now how is debhelper supposed to tell these two cases apart? I can think
of a few ways, but they're all fairly complicated and fragile.

Policy is actually careful to set up the invarient that "-" anywhere in
a version number means the package is not native. I don't know why the
developers reference choses to ignore that. Is there something wrong
with using a version number like "1.0.0.1" for native package NMUs?
(Being careful to choose one that is well outside the normal range.
"1.0.debian.1" if necessary.)

-- 
see shy jo


signature.asc
Description: Digital signature