[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GPL issues (Re: sources for Knoppix 4.02)

On Thu, Jul 13, 2006 at 12:04:19AM +0200, Klaus Knopper wrote:
> On Wed, Jul 12, 2006 at 04:26:56PM -0500, Dirk Eddelbuettel wrote:
>> On Wed, Jul 12, 2006 at 10:34:09PM +0200, Klaus Knopper wrote:

>>> So, what about this:

>>> $ dpkg-query -W --showformat='${Package} ${Version} ${Source}\n' e2fsprogs
>>> e2fsprogs 1.38+1.39-WIP-2006.04.09-1

>>> What would be the source package? Your best guess?

As I told you, the source package is e2fsprogs, version

>> I may misunderstand your question here. 

>> In the case of e2fsprogs, the Debian maintainer *is* the upstream
>> maintainer. In those cases packages may have been 'native' to
>> Debian ie have no Debian revision number.

Read the version string! In this case it _is_ packaged as a non-native
package and it _does_ have a Debian revision number, namely "1".

> Ok so far. So, the revision number is 1.38+1.39-WIP-2006.04.09?

1.38+1.39-WIP-2006.04.09-1 parses as:

 epoch: 0
 upstream version: 1.38+1.39-WIP-2006.04.09
 Debian revision: 1

>> Ted seems to have packaged a WIP (work in progress, maybe?)
>> snapshot between releases 1.38 and 1.39, and taken on April 9.

True, but totally unrelated to the matter at hand.

>> The pool structure, I believe, keeps the sources for the current
>> stable, testing and unstable versions.

> The snapshots mirror does this. However, there is no source package
> that matches the version number of the corresponding binary,

There is:

 master@bagnat:~$ apt-get source e2fsprogs=1.38+1.39-WIP-2006.04.09-1
 Reading package lists... Done
 Building dependency tree... Done
 Need to get 3691kB of source archives.
 Get: 1 http://snapshot.debian.net pool/e2fsprogs e2fsprogs 1.38+1.39-WIP-2006.04.09-1 (dsc) [876B]
 Get: 2 http://snapshot.debian.net pool/e2fsprogs e2fsprogs 1.38+1.39-WIP-2006.04.09-1 (tar) [3690kB]
 Get: 3 http://snapshot.debian.net pool/e2fsprogs e2fsprogs 1.38+1.39-WIP-2006.04.09-1 (diff) [20B]
 Fetched 3691kB in 18s (200kB/s)

>> Now, as to the peculiar reply from dpkg-query, it would appear that
>> ${Source} returns a "source package name" if and only if that name is

> Actually, "${Source}" returns "Source-Packagename
> (version-of-sourcepackage)". But this field aisn't present in the
> example e2fsprogs package.

Apparently, this is because the source package has the same name. I
don't know why we don't just always put the name of the source in that
field, and only when it differs.

>> different from the binary package name -- see here for a small package where
>> source==binary, and another example where that is not the case:

>> edd@basebud:~> dpkg-query -W --showformat='${Package} -- ${Version} -- ${Source}\n' wajig
>> wajig -- 2.0.34 --
>> edd@basebud:~> dpkg-query -W --showformat='${Package} -- ${Version} -- ${Source}\n' r-base-core
>> r-base-core -- 2.3.1-1 -- r-base

>> So maybe dpkg-query wasn't meant to be used the way you are trying to use it?

> It should be able to fetch the source package name and version
> number (if they differ from the binary package name, which is the
> case here).

It is not the case. binary: e2fsprogs, source: e2fsprogs, version
string: the same.

> The version number inside that .deb package should IMHO not differ
> from the version number shown in the source package, for this
> subpackages source.

As far as I know, the only case where the version differs is binary
rebuilds, that is a "+bNNNN" suffix. If you have another example,
please tell me.

> Maybe there is a policy for it, maybe not. But in any case, finding
> sources with mismatching versioning information, is not easy.
> Sometimes you have to guess and unpack the source to see what
> strange or wonderful things the maintainer has written in
> debian/rules to create this versioning scheme.

You have an example of this?


Reply to: