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

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

Hi Dirk,

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:
> > On Tue, Jul 11, 2006 at 10:22:20PM -0500, Dirk Eddelbuettel wrote:
> > > 
> > > On 11 July 2006 at 13:45, Lionel Elie Mamane wrote:
> > > | On Tue, Jul 04, 2006 at 11:05:02AM -0500, Dirk Eddelbuettel wrote:
> > > | 
> > > | > Let's start from first principles. A Debian package has a name
> > > | > matching a regexp package_1.2.3-1_arch.deb.  Note the two
> > > | > underscores delineating the combined 'upstream-debian' version
> > > | > number.  There is only one hyphen, and it separates the upstream
> > > | > number from the Debian number.
> > > | 
> > > | There may be more than one hyphen; the _last_ one is the separator
> > > | (Debian policy 5.6.12).
> > > 
> > > Thanks for catching that. I had it in the back of my mind as I even vaguely
> > > recall Ian Jackson discussing this in the mid nineties. I should have looked
> > > it up. So the heuristic is
> > > 
> > > -- parse from the left for the first '_' to get the name
> > > -- parse from the right for the first '-' to get the Debian revision
> > > -- the remainder the is the upstream version, or whatever modification was
> > >    done to it (e.g. adding '.csv.20060711' or some such).
> > 
> > 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?
> 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.

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

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


> in the thread, the point is also moot as the current file in unstable and
> testing is e2fsprogs_1.39-1.

Not exactly, because everyone who ships the binary version
1.38+1.39-WIP-2006.04.09-1, must be able to produce the source for
1.38+1.39-WIP-2006.04.09-1 as well. Not for an earlier, or later

> 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, and as the above
command shows, there is also no "Source" field in the package that
contains the REAL version number, or name (if it differs) of the source
package either.

This is just an example. There are more packages like this. One of them
is gcc-base, but I figured that one out meanwhile (it has a "source
(version) field).

> So currently there is none corresponding to
> your snapshot. But you could simply fetch the current package from testing or
> unstable, and get its sources.  That would satisfy the GPL for all, no?

No. The GPL says yu must produce the source for the binary you ship, if
you have chosen §3b from the GPL as source distribution method. So, if
you want to setup a source archive for your binaries, and seek for the
source package matching a binary you downloaded earlier, you are in
trouble if the mirror has been updated meanwhile. Considering the
frequency in which unstable packages are replaced, it is not an unlikely
case that it is not possible to apt-get source -t unstable the same
package that you installed with apt-get install -t unstable a few
minutes before. So, if yu search the snapshot mirror, you'll have a hard
time finding the source package that matches the binary package, if the
version number is misnamed.

> 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.

> 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).

The version number inside that .deb package should IMHO not differ from
the version number shown in the source package, for this subpackages
source. 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.


Reply to: