Re: Distinguishing native package / package with upstream

2016-12-11 Thread Christoph Biedl
Christian Seiler wrote...

> Lintian has warnings for this btw.:
> 
> https://lintian.debian.org/tags/native-package-with-dash-version.html
> https://lintian.debian.org/tags/non-native-package-with-native-version.html

Ah, should have thought of lintian. So things like this happen but
certainly are frowned upon.

> So yeah, it appears that you really have to look at the .dsc to
> determine whether a package is native or not.

Not my preferred answer, but that's the way it is. Thanks for the swift
response.

Christoph


signature.asc
Description: Digital signature


Re: Distinguishing native package / package with upstream

2016-12-10 Thread Sean Whitton
On Sat, Dec 10, 2016 at 06:28:58PM +0100, Christian Seiler wrote:
> On 12/10/2016 06:03 PM, Christoph Biedl wrote:
> > So, in order to decide native/with upstream, do I really have to take
> > a look into the .dsc file? Or is the above something that should not
> > happen?
> [...]
> So yeah, it appears that you really have to look at the .dsc to
> determine whether a package is native or not.

Not quite the question you asked, but if you want to avoid erroneously
native uploads, using debuild rather than dpkg-buildpackage does a check
for the existence of the orig.tar.  This is useful because if the
orig.tar is not present, dpkg-buildpackage can build a native package
when you want a non-native.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Distinguishing native package / package with upstream

2016-12-10 Thread Christian Seiler
On 12/10/2016 06:03 PM, Christoph Biedl wrote:
> Then I stumbled across a package that has in its .dsc file:
> 
> | Format: 1.0
> | Source: package-name
> | (...)
> | Version: 4.3.2-1
> | (...)
> | Files:
> |  0123456789abcdef0123456789abcdef 12345 package-name_4.3.2-1.tar.gz
> 
> While the version number contains a hyphen it's certainly native.
> Additionally, the upload was quite recently (in fall 2016) so it's not a
> legacy from the old rough times.
> 
> So, in order to decide native/with upstream, do I really have to take
> a look into the .dsc file? Or is the above something that should not
> happen?

I believe that this is wrong. You should either have a native package
with a single .tar.gz (no .diff.gz or .debian.tar.gz), or a non-native
package with a .orig.tar.gz together with a .diff.gz (d/source/format
"1.0") or .debian.tar.gz (d/source/format "3.0 (quilt)").

Lintian has warnings for this btw.:

https://lintian.debian.org/tags/native-package-with-dash-version.html
https://lintian.debian.org/tags/non-native-package-with-native-version.html

OTOH, some people appear to have overridden that warning, at least one
example I checked appears to be a meta-package that shadows the version
of the package it selects... And in that case there's a good reason to
also include the Debian revision in there, which is why the override is
likely valid. (In the cases where it's not overridden it's probably a
mistake though.)

So yeah, it appears that you really have to look at the .dsc to
determine whether a package is native or not.

Regards,
Christian



Distinguishing native package / package with upstream

2016-12-10 Thread Christoph Biedl
Hello,

this might sound like a trick question: What is the reliable method
to tell whether a certain Debian package is native, or has been taken
from an upstream?

Until today I thought the version number was a sane indicator: If it
contains a hyphen, it's a package with upstream. Otherwise it's native.
My understanding of policy 5.6.12 supports this.

Then I stumbled across a package that has in its .dsc file:

| Format: 1.0
| Source: package-name
| (...)
| Version: 4.3.2-1
| (...)
| Files:
|  0123456789abcdef0123456789abcdef 12345 package-name_4.3.2-1.tar.gz

While the version number contains a hyphen it's certainly native.
Additionally, the upload was quite recently (in fall 2016) so it's not a
legacy from the old rough times.

So, in order to decide native/with upstream, do I really have to take
a look into the .dsc file? Or is the above something that should not
happen?

Christoph


signature.asc
Description: Digital signature