Debian Bug report logs - #344280
wxwidgets2.6 is not a native Debian package

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@stusta.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: wxwidgets2.6 is not a native Debian package

Date: Wed, 21 Dec 2005 15:27:59 +0100

Package: wxwidgets2.6
Version: 2.6.1.2
Severity: normal

wxwidgets2.6 was not "written specifically to be turned into a
Debian package".

It should therefore be packaged as a non-native package
(.orig.tar.gz + .diff.gz + .dsc), and the versionnumber should
include a Debian revision.

Message #10 received at 344280-done@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Adrian Bunk <bunk@stusta.de>, 344280-done@bugs.debian.org

Subject: Re: Bug#344280: wxwidgets2.6 is not a native Debian package

Date: Thu, 22 Dec 2005 04:27:41 +1030

On Wed, Dec 21, 2005 at 03:27:59PM +0100, Adrian Bunk wrote:
> Package: wxwidgets2.6
> Version: 2.6.1.2
> Severity: normal
> 
> wxwidgets2.6 was not "written specifically to be turned into a
> Debian package".
> 
> It should therefore be packaged as a non-native package
> (.orig.tar.gz + .diff.gz + .dsc), and the versionnumber should
> include a Debian revision.

There is no diff.gz.  I'm open to technical suggestions for
how 'non-native' but wholly unmodified upstream source releases
might be packaged better, but I WILL NOT include a zero length
diff.gz for upload just to satisfy semantic nit-picking on what
is and is not 'native'.

We've bashed this one to death several times before, I think I
know all the arguments for each side -- possibly the new separate
debian dir thing may be of some use here, but I've yet to see a
working example to demonstrate its relevance, and haven't had
time to toy with it more myself yet.

Efforts to fix the underlying problem will be appreciated, but
until the existence of a diff.gz and use of a 'debian revision'
are less tightly linked together, the typically suggested 'cure'
is not warranted by any natural problem in evidence.

If the package is uploaded with a real diff.gz then it should
have a debian version -- since it typically is not, the tools
dictate it should not have one.  That is the real bug, if any,
here.  I'm not sure who is interested in addressing it (this
isn't new), but there is nothing 'broken' to 'fix' at this end
that cannot be fixed more thoroughly and permanently in other
places.

Sorry, I want the big picture fixed for this one,
Ron

Message #15 received at 344280@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@stusta.de>

To: Ron <ron@debian.org>

Cc: 344280@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#344280: wxwidgets2.6 is not a native Debian package

Date: Wed, 21 Dec 2005 19:19:57 +0100

reopen 344280
thanks

On Thu, Dec 22, 2005 at 04:27:41AM +1030, Ron wrote:
> On Wed, Dec 21, 2005 at 03:27:59PM +0100, Adrian Bunk wrote:
> > Package: wxwidgets2.6
> > Version: 2.6.1.2
> > Severity: normal
> > 
> > wxwidgets2.6 was not "written specifically to be turned into a
> > Debian package".
> > 
> > It should therefore be packaged as a non-native package
> > (.orig.tar.gz + .diff.gz + .dsc), and the versionnumber should
> > include a Debian revision.
> 
> There is no diff.gz.  I'm open to technical suggestions for
> how 'non-native' but wholly unmodified upstream source releases
> might be packaged better, but I WILL NOT include a zero length
> diff.gz for upload just to satisfy semantic nit-picking on what
> is and is not 'native'.
>...

You will never have a zero length .diff.gz simply because the .diff.gz 
contains your modifications to the upstream sources _including_ your 
debian/ subdir.

And with a .diff.gz it would e.g. be possible to see how dcclient.cpp 
differs from the pristine upstream sources.

As a bonus, you wouldn't upload 15 MB to all mirrors for each change in 
the packaging.

> Efforts to fix the underlying problem will be appreciated, but
> until the existence of a diff.gz and use of a 'debian revision'
> are less tightly linked together, the typically suggested 'cure'
> is not warranted by any natural problem in evidence.

Your current versioning implies there were _upstream_ versions 
2.6.1.1.1 and 2.6.1.2, but there aren't.

> If the package is uploaded with a real diff.gz then it should
> have a debian version -- since it typically is not, the tools
> dictate it should not have one.  That is the real bug, if any,
> here.  I'm not sure who is interested in addressing it (this
> isn't new), but there is nothing 'broken' to 'fix' at this end
> that cannot be fixed more thoroughly and permanently in other
> places.
>...

It would be correct even if .diff.gz was empty, but as I explained above 
your assumption your .diff.gz would be empty is wrong.

> Ron

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Message #22 received at 344280-done@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Adrian Bunk <bunk@stusta.de>, 344280-done@bugs.debian.org

Subject: Re: Bug#344280: wxwidgets2.6 is not a native Debian package

Date: Thu, 22 Dec 2005 14:50:07 +1030

On Wed, Dec 21, 2005 at 07:19:57PM +0100, Adrian Bunk wrote:
> On Thu, Dec 22, 2005 at 04:27:41AM +1030, Ron wrote:
> > On Wed, Dec 21, 2005 at 03:27:59PM +0100, Adrian Bunk wrote:
> > > Package: wxwidgets2.6
> > > Version: 2.6.1.2
> > > Severity: normal
> > > 
> > > wxwidgets2.6 was not "written specifically to be turned into a
> > > Debian package".
> > > 
> > > It should therefore be packaged as a non-native package
> > > (.orig.tar.gz + .diff.gz + .dsc), and the versionnumber should
> > > include a Debian revision.
> > 
> > There is no diff.gz.  I'm open to technical suggestions for
> > how 'non-native' but wholly unmodified upstream source releases
> > might be packaged better, but I WILL NOT include a zero length
> > diff.gz for upload just to satisfy semantic nit-picking on what
> > is and is not 'native'.
> >...
> 
> You will never have a zero length .diff.gz simply because the .diff.gz 
> contains your modifications to the upstream sources _including_ your 
> debian/ subdir.

This is why there will never be anything _but_ a zero length diff.gz
for uploads I make.  All changes that I make, _including_ the debian/
dir, are made to the upstream cvs repository before they are uploaded
to Debian.  I understand that doing that does expose a few edge cases
in our definition of what is 'native' -- but the extra work I would
need to do to maintain a "conventional separation" (that simply does not
exist in (most of) the present circumstances surrounding this package)
has not been justified by the so far very few times it would have been
a real advantage somewhere.

If someone were to upload a package containing Debian specific changes
that were not propagated to the upstream maintainers, then yes, I would
expect that upload to include a diff.gz as per its intended purpose.

But I confess I'm not sure what interesting things will occur in the
ftp archive if the package should flip between states from time to time.
In practice, its yet to happen...

> And with a .diff.gz it would e.g. be possible to see how dcclient.cpp 
> differs from the pristine upstream sources.

You'll have to be more explicit here.  I haven't changed dcclient for
more than 5 years now if cvs logs are to be believed (and never outside
of the pristine source).  I suspect you are doing a diff between different
source releases and noting changes that occurred naturally in cvs in the
time between them.

> As a bonus, you wouldn't upload 15 MB to all mirrors for each change in 
> the packaging.

Yes, once or twice this would have been a plus for me.  And I know
the ubuntu folk would have benefitted from this.  But the extra
unnecessary work for all other uploads easily swamp any gains I'd
have historically made to date.

There are always plenty of upstream bugs that can be fixed along
with any package fiddling that might occur ;-)

And I try not to upload 'too often' for exactly the reason that
this is a _big_ package and users all have to download it again
for each alteration.  This nicely limits frivolous ones ;-)


> > Efforts to fix the underlying problem will be appreciated, but
> > until the existence of a diff.gz and use of a 'debian revision'
> > are less tightly linked together, the typically suggested 'cure'
> > is not warranted by any natural problem in evidence.
> 
> Your current versioning implies there were _upstream_ versions 
> 2.6.1.1.1 and 2.6.1.2, but there aren't.

There ARE.  That is my point.  But I don't pretend this is obvious
to anyone assuming that wx works like other projects they are
familiar with.  And the fact that the 2.6 branch is in something
of a mess and some tags did not get applied when they should does
not make it any clearer.

wx does not release a 'one true source' tarball like lk and many
smaller projects do.  We support many disparate platforms, which
implies that for any particular platform, there is going to be
a lot of totally unrelated "cruft" in a 'whole source' tarball.

So we keep it all in cvs, tag the files linked to any particular
release, and than crank out a set of more specifically focussed
source releases.  This way debian users don't get affected when
the OS/2 developers (to pick a random example) find a critical
bug that requires them to re-release immediately.  But it does
mean we are not always exactly in sync with them.

So you may not (and indeed in this case, will not) find alternative
source packages using the same release number.  They are released
with 'between' version numbers precisely to indicate that they are
not the result of a fully synchronised release on all platforms,
but rather contain errata of interest to the platform(s) they
were released for.

We almost always run on some such minor release, as wxPython
inevitably finds bugs in its testing phase after the C++ libs
are tagged for release.

The Debian source however is always generated directly from my
cvs working directory -- no changes are ever made outside that
scope, so it strictly tracks changes that have or will be made
upstream.

If we ever make an 'official' release that isn't instantly
broken in some way, you'll see a lot fewer diffs between
the different source tarballs...  but these releases are no
less 'upstream' just because they are uploaded to ftp.d.o
than they would be if they were also uploaded (much less usefully)
to ftp.sf.net or similar as well.

The handle was turned on cvs.  A numbered release popped out.
It was uploaded to the usual distribution site.  No Debian specific
changes were made between there and the end users.  Other distributors
may or may not release from the same tag.

> > If the package is uploaded with a real diff.gz then it should
> > have a debian version -- since it typically is not, the tools
> > dictate it should not have one.  That is the real bug, if any,
> > here.  I'm not sure who is interested in addressing it (this
> > isn't new), but there is nothing 'broken' to 'fix' at this end
> > that cannot be fixed more thoroughly and permanently in other
> > places.
> >...
> 
> It would be correct even if .diff.gz was empty, but as I explained above 
> your assumption your .diff.gz would be empty is wrong.

If we are going to argue this, lets not assume I'm naively
unaware of the Right Thing to do according to policy and
best practice, or didn't think through what I did do.
wx is weird in a number of ways and frustrating in a fair
number of others.

I think the current packaging best reflects the nature of the
source it is created from, within the technical constraints
of the tools.  I agree that overloading the social idea of
a 'native' package with the technical issue of 'no diff.gz'
clouds the real issue of why this package is like it is, and
why it perhaps should be different in a perfect world.

I'm not trying to indicate this is a package exclusive to
Debian, but the tools assume this if no Debian specific
changes are actually made.  If we are going to push the
tightest interpretation of what is a 'native' package,
then we need a better way to indicate that a wholly pristine
upstream source has been uploaded, for something which also
has uses outside of Debian, but supports it without need for
any change.  (clearly the latter is an optimum if uncommon
situation, despite the feeling of some developers re the
debian/ that _their_ upstream source supplies, but I cannot
help that ;-)

The main reason I prefer not to keep this open, tagged wontfix,
is that these sort of things tend to become polling booths for
anyone with a spare minute and a me too.  In ways that are
rarely productive.

I might add a FAQ to the package, or a wiki entry somewhere,
that summarises the debate to date though.  I have no objection
to seeing the apparent 'conflict' here resolved, and invite
intelligent arguments as to how we might do it, but I must
reject the idea that policy (re)definitions of what is 'native'
take precedence over the fundamental reasons for having a
diff.gz in the first place where the two are in conflict.

The best hope I've seen so far is the possibility that the
tools may (now) support using separate upstream.tar.gz and
debian.tar.gz (with no diff.gz) -- in which case I can fairly
sensibly just crank two tarballs out of my working dir instead
of one.  An extra file to juggle is much less heinous than
an entire redundant source tree.

But I've yet to see if that is really possible, or just
wishful thinking based on descriptions of new features...

Patches and clues down that line would be most welcome.

cheers,
Ron

Message #27 received at 344280@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@stusta.de>

To: Ron <ron@debian.org>

Cc: 344280@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#344280: wxwidgets2.6 is not a native Debian package

Date: Thu, 22 Dec 2005 05:59:41 +0100

reopen 344280
thanks

On Thu, Dec 22, 2005 at 02:50:07PM +1030, Ron wrote:
> On Wed, Dec 21, 2005 at 07:19:57PM +0100, Adrian Bunk wrote:
> > On Thu, Dec 22, 2005 at 04:27:41AM +1030, Ron wrote:
> > > On Wed, Dec 21, 2005 at 03:27:59PM +0100, Adrian Bunk wrote:
> > > > Package: wxwidgets2.6
> > > > Version: 2.6.1.2
> > > > Severity: normal
> > > > 
> > > > wxwidgets2.6 was not "written specifically to be turned into a
> > > > Debian package".
> > > > 
> > > > It should therefore be packaged as a non-native package
> > > > (.orig.tar.gz + .diff.gz + .dsc), and the versionnumber should
> > > > include a Debian revision.
> > > 
> > > There is no diff.gz.  I'm open to technical suggestions for
> > > how 'non-native' but wholly unmodified upstream source releases
> > > might be packaged better, but I WILL NOT include a zero length
> > > diff.gz for upload just to satisfy semantic nit-picking on what
> > > is and is not 'native'.
> > >...
> > 
> > You will never have a zero length .diff.gz simply because the .diff.gz 
> > contains your modifications to the upstream sources _including_ your 
> > debian/ subdir.
> 
> This is why there will never be anything _but_ a zero length diff.gz
> for uploads I make.  All changes that I make, _including_ the debian/
> dir, are made to the upstream cvs repository before they are uploaded
> to Debian.  I understand that doing that does expose a few edge cases
> in our definition of what is 'native' -- but the extra work I would
> need to do to maintain a "conventional separation" (that simply does not
> exist in (most of) the present circumstances surrounding this package)
> has not been justified by the so far very few times it would have been
> a real advantage somewhere.

But the upstream tarballs don't contain the debian/ subdirs.

> If someone were to upload a package containing Debian specific changes
> that were not propagated to the upstream maintainers, then yes, I would
> expect that upload to include a diff.gz as per its intended purpose.
> 
> But I confess I'm not sure what interesting things will occur in the
> ftp archive if the package should flip between states from time to time.
> In practice, its yet to happen...

If someone does a source NMU for wxwidgets2.6, this upload will 
currently _not_ contain a .diff.gz since your package is being treated   
as native effectively creating a new upstream version.

Currently, an NMU would be an upload of a 15 MB source tarball with the 
version 2.6.1.2-0.1 .

> > And with a .diff.gz it would e.g. be possible to see how dcclient.cpp 
> > differs from the pristine upstream sources.
> 
> You'll have to be more explicit here.  I haven't changed dcclient for
> more than 5 years now if cvs logs are to be believed (and never outside
> of the pristine source).  I suspect you are doing a diff between different
> source releases and noting changes that occurred naturally in cvs in the
> time between them.

From your latest upload:

wxwidgets2.6 (2.6.1.2) unstable; urgency=low
...
  * Pull in changes to dcclient.cpp and window.cpp from HEAD
    mostly for gtk2.8 compatibility, but fixes a couple of
    other issues too.

 -- Ron Lee <ron@debian.org>  Thu, 25 Aug 2005 18:38:31 +0930

It's a bit strange that on the one hand you insist that a .diff.gz was 
empty because all changes you make were already in the upstream cvs, but 
on the other hand you stated in your latest upload that you did change 
the upstream sources in some way.

> > As a bonus, you wouldn't upload 15 MB to all mirrors for each change in 
> > the packaging.
> 
> Yes, once or twice this would have been a plus for me.  And I know
> the ubuntu folk would have benefitted from this.  But the extra
> unnecessary work for all other uploads easily swamp any gains I'd
> have historically made to date.
>...

What are the gains from not shipping a .diff.gz (empty or not) and 
not using a Debian revision in the package version?

> > > Efforts to fix the underlying problem will be appreciated, but
> > > until the existence of a diff.gz and use of a 'debian revision'
> > > are less tightly linked together, the typically suggested 'cure'
> > > is not warranted by any natural problem in evidence.
> > 
> > Your current versioning implies there were _upstream_ versions 
> > 2.6.1.1.1 and 2.6.1.2, but there aren't.
> 
> There ARE.  That is my point.  But I don't pretend this is obvious
> to anyone assuming that wx works like other projects they are
> familiar with.  And the fact that the 2.6 branch is in something
> of a mess and some tags did not get applied when they should does
> not make it any clearer.
> 
> wx does not release a 'one true source' tarball like lk and many
> smaller projects do.  We support many disparate platforms, which
> implies that for any particular platform, there is going to be
> a lot of totally unrelated "cruft" in a 'whole source' tarball.
> 
> So we keep it all in cvs, tag the files linked to any particular
> release, and than crank out a set of more specifically focussed
> source releases.  This way debian users don't get affected when
> the OS/2 developers (to pick a random example) find a critical
> bug that requires them to re-release immediately.  But it does
> mean we are not always exactly in sync with them.

You don't have to upload a new Debian package when an OS/2 bug was 
fixed.

But I'd e.g. expect what was packaged as "2.6.0" being the official
wxWidgets 2.6.0 tarball plus some Debian packaging and perhaps some 
fixes.

> So you may not (and indeed in this case, will not) find alternative
> source packages using the same release number.  They are released
> with 'between' version numbers precisely to indicate that they are
> not the result of a fully synchronised release on all platforms,
> but rather contain errata of interest to the platform(s) they
> were released for.
> 
> We almost always run on some such minor release, as wxPython
> inevitably finds bugs in its testing phase after the C++ libs
> are tagged for release.

It's common for many packages to sometimes package cvs snapshots, but 
that's not a reason for a native packaging.

> The Debian source however is always generated directly from my
> cvs working directory -- no changes are ever made outside that
> scope, so it strictly tracks changes that have or will be made
> upstream.

Your "cvs working directory" contains upstream sources plus your Debian 
packaging.

Many other debian developers do their work in an upstream or local cvs 
or Subversion repository, but that's not a reason for a native 
packaging.

> If we ever make an 'official' release that isn't instantly
> broken in some way, you'll see a lot fewer diffs between
> the different source tarballs...  but these releases are no
> less 'upstream' just because they are uploaded to ftp.d.o
> than they would be if they were also uploaded (much less usefully)
> to ftp.sf.net or similar as well.
> 
> The handle was turned on cvs.  A numbered release popped out.
> It was uploaded to the usual distribution site.  No Debian specific
> changes were made between there and the end users.  Other distributors
> may or may not release from the same tag.

This still doesn't make it "a piece of software was written specifically 
to be turned into a Debian package".

> > > If the package is uploaded with a real diff.gz then it should
> > > have a debian version -- since it typically is not, the tools
> > > dictate it should not have one.  That is the real bug, if any,
> > > here.  I'm not sure who is interested in addressing it (this
> > > isn't new), but there is nothing 'broken' to 'fix' at this end
> > > that cannot be fixed more thoroughly and permanently in other
> > > places.
> > >...
> > 
> > It would be correct even if .diff.gz was empty, but as I explained above 
> > your assumption your .diff.gz would be empty is wrong.
> 
> If we are going to argue this, lets not assume I'm naively
> unaware of the Right Thing to do according to policy and
> best practice, or didn't think through what I did do.
> wx is weird in a number of ways and frustrating in a fair
> number of others.
> 
> I think the current packaging best reflects the nature of the
> source it is created from, within the technical constraints
> of the tools.  I agree that overloading the social idea of
> a 'native' package with the technical issue of 'no diff.gz'
> clouds the real issue of why this package is like it is, and
> why it perhaps should be different in a perfect world.

What's so extremely imperfect on an empty .diff.gz?

Especially considering that it can't be empty when you package an 
upstream version whose official tarball does not contain a debian/ 
directory?

> I'm not trying to indicate this is a package exclusive to
> Debian, but the tools assume this if no Debian specific
> changes are actually made.  If we are going to push the
> tightest interpretation of what is a 'native' package,
> then we need a better way to indicate that a wholly pristine
> upstream source has been uploaded, for something which also
> has uses outside of Debian, but supports it without need for
> any change.  (clearly the latter is an optimum if uncommon
> situation, despite the feeling of some developers re the
> debian/ that _their_ upstream source supplies, but I cannot
> help that ;-)

The tools do not assume that a package was native if no Debian specific 
changes are actually made.

The tools assume a package was native if the maintainer forgot to put an 
.orig.tar.gz at the expected place...

> The main reason I prefer not to keep this open, tagged wontfix,
> is that these sort of things tend to become polling booths for
> anyone with a spare minute and a me too.  In ways that are
> rarely productive.
> 
> I might add a FAQ to the package, or a wiki entry somewhere,
> that summarises the debate to date though.  I have no objection
> to seeing the apparent 'conflict' here resolved, and invite
> intelligent arguments as to how we might do it, but I must
> reject the idea that policy (re)definitions of what is 'native'
> take precedence over the fundamental reasons for having a
> diff.gz in the first place where the two are in conflict.

I see neither any technical problem with an empty .diff.gz nor with 
adding a Debian revision to the package version.

Many Debian developers are upstream of the packages they maintain, and 
this has never been a problem.

> The best hope I've seen so far is the possibility that the
> tools may (now) support using separate upstream.tar.gz and
> debian.tar.gz (with no diff.gz) -- in which case I can fairly
> sensibly just crank two tarballs out of my working dir instead
> of one.  An extra file to juggle is much less heinous than
> an entire redundant source tree.

You can e.g. simply copy the debian/ subdir from your working dir to the 
upstream working directory, and this directory will get into the 
.diff.gz.

That's more or less how all non-native packages work, so where's the 
problem?

> But I've yet to see if that is really possible, or just
> wishful thinking based on descriptions of new features...
> 
> Patches and clues down that line would be most welcome.
> 
> cheers,
> Ron

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Message #34 received at 344280-done@bugs.debian.org (full text, mbox, reply):

From: Ron <ron@debian.org>

To: Adrian Bunk <bunk@stusta.de>, 344280-done@bugs.debian.org

Subject: Re: Bug#344280: wxwidgets2.6 is not a native Debian package

Date: Thu, 22 Dec 2005 18:46:38 +1030

On Thu, Dec 22, 2005 at 05:59:41AM +0100, Adrian Bunk wrote:
> reopen 344280

Please let's not play this game.  You have my explanations why
an open bug is no assistance to solving the problem.

> thanks
> 
> On Thu, Dec 22, 2005 at 02:50:07PM +1030, Ron wrote:
> > On Wed, Dec 21, 2005 at 07:19:57PM +0100, Adrian Bunk wrote:
> > > On Thu, Dec 22, 2005 at 04:27:41AM +1030, Ron wrote:
> > > > On Wed, Dec 21, 2005 at 03:27:59PM +0100, Adrian Bunk wrote:
> > > > > Package: wxwidgets2.6
> > > > > Version: 2.6.1.2
> > > > > Severity: normal
> > > > > 
> > > > > wxwidgets2.6 was not "written specifically to be turned into a
> > > > > Debian package".
> > > > > 
> > > > > It should therefore be packaged as a non-native package
> > > > > (.orig.tar.gz + .diff.gz + .dsc), and the versionnumber should
> > > > > include a Debian revision.
> > > > 
> > > > There is no diff.gz.  I'm open to technical suggestions for
> > > > how 'non-native' but wholly unmodified upstream source releases
> > > > might be packaged better, but I WILL NOT include a zero length
> > > > diff.gz for upload just to satisfy semantic nit-picking on what
> > > > is and is not 'native'.
> > > >...
> > > 
> > > You will never have a zero length .diff.gz simply because the .diff.gz 
> > > contains your modifications to the upstream sources _including_ your 
> > > debian/ subdir.
> > 
> > This is why there will never be anything _but_ a zero length diff.gz
> > for uploads I make.  All changes that I make, _including_ the debian/
> > dir, are made to the upstream cvs repository before they are uploaded
> > to Debian.  I understand that doing that does expose a few edge cases
> > in our definition of what is 'native' -- but the extra work I would
> > need to do to maintain a "conventional separation" (that simply does not
> > exist in (most of) the present circumstances surrounding this package)
> > has not been justified by the so far very few times it would have been
> > a real advantage somewhere.
> 
> But the upstream tarballs don't contain the debian/ subdirs.

Of course they do.  The scripts (in cvs) that create them include
everything that is required for the target platform, and have done
so for years.  wxwidgets2.6_2.6.1.2.tar.gz _is_ a pristine upstream
release tarball.  One of a number that get made by various people.

It doesn't contain .spec files for rpms, nor source for platforms
unsupported by Debian, nor a bunch of other ancillary things from
the whole source repository.  Likewise distribution bundles meant
for other targets, often do not contain debian/ ...

That you looked in one of these does not change the fact this _is_
an upstream tarball.  I don't really care how it is numbered, but
it is the One True Upstream tar.gz.  And it does contain the
debian/ subdirs as they appear in cvs when it is created.

> > If someone were to upload a package containing Debian specific changes
> > that were not propagated to the upstream maintainers, then yes, I would
> > expect that upload to include a diff.gz as per its intended purpose.
> > 
> > But I confess I'm not sure what interesting things will occur in the
> > ftp archive if the package should flip between states from time to time.
> > In practice, its yet to happen...
> 
> If someone does a source NMU for wxwidgets2.6, this upload will 
> currently _not_ contain a .diff.gz since your package is being treated   
> as native effectively creating a new upstream version.

Ideally of course, they should preserve the original tar.gz as
orig.tar.gz and make their changes in such a way that a diff.gz
will be created.  (But in practice, people send me a patch, I
apply it to cvs and we make a new release...)

> Currently, an NMU would be an upload of a 15 MB source tarball with the 
> version 2.6.1.2-0.1 .

Yes.  This is unfortunate, but presently still the lesser of evils
to choose from.  And so rare an occurrence historically as to be
practically hypothetical.

> > > And with a .diff.gz it would e.g. be possible to see how dcclient.cpp 
> > > differs from the pristine upstream sources.
> > 
> > You'll have to be more explicit here.  I haven't changed dcclient for
> > more than 5 years now if cvs logs are to be believed (and never outside
> > of the pristine source).  I suspect you are doing a diff between different
> > source releases and noting changes that occurred naturally in cvs in the
> > time between them.
> 
> >From your latest upload:
> 
> wxwidgets2.6 (2.6.1.2) unstable; urgency=low
> ...
>   * Pull in changes to dcclient.cpp and window.cpp from HEAD
>     mostly for gtk2.8 compatibility, but fixes a couple of
>     other issues too.
> 
>  -- Ron Lee <ron@debian.org>  Thu, 25 Aug 2005 18:38:31 +0930
> 
> It's a bit strange that on the one hand you insist that a .diff.gz was 
> empty because all changes you make were already in the upstream cvs, but 
> on the other hand you stated in your latest upload that you did change 
> the upstream sources in some way.

Yes.  Perhaps my comments were not clear, but I pulled in new changes
from cvs HEAD above and beyond the other changes documented there.
It was the only change to the C++ library from the previous release.

I imported important changes made to cvs _after_ that snapshot was
already well into being tested.  2.6 had not branched still at that
stage and development on HEAD was still pretty feral.  I was being
selective about which versions of what files would be in the next
release and omitting hasty last minute mods made by some people.
ie. Doing Good Release Management.

I still might pull selected patches from HEAD into the 2.6 branch
in future though, none of those will be Debian specific or belong
in a diff.gz so I'm not sure what the misunderstanding is here...

Work in cvs by others does not stop just because I am preparing
and testing a release for Debian et al.  That is what we have tags
for.  But sometimes things they do clearly should be incorporated
before a release is finally uploaded.  That is all that happened
there.

> > > As a bonus, you wouldn't upload 15 MB to all mirrors for each change in 
> > > the packaging.
> > 
> > Yes, once or twice this would have been a plus for me.  And I know
> > the ubuntu folk would have benefitted from this.  But the extra
> > unnecessary work for all other uploads easily swamp any gains I'd
> > have historically made to date.
> >...
> 
> What are the gains from not shipping a .diff.gz (empty or not) and 
> not using a Debian revision in the package version?

Aside from the ugly aesthetic of the former, I halve the number
of large tarballs I need to handle to spin each release for
testing.  Remember all those Mb I'd be saving on a NMU.  They are
the ones my swap would be thrashing clones of into my otherwise
useful HD space, for every single test build, uploaded or not.

For every single typo fix, I'd need to sync two source dirs
(and a third if I'm to make the fix to cvs too) -- as opposed
to my current practice, of fixing the single authoritative
source, spinning a new tarball to test, and simply committing
if all goes well, uploading if all preliminary tests are ok.

wx has enough problems to fix without spending (more) precious
time sitting and listening to my HD warm the room pointlessly.

> > > > Efforts to fix the underlying problem will be appreciated, but
> > > > until the existence of a diff.gz and use of a 'debian revision'
> > > > are less tightly linked together, the typically suggested 'cure'
> > > > is not warranted by any natural problem in evidence.
> > > 
> > > Your current versioning implies there were _upstream_ versions 
> > > 2.6.1.1.1 and 2.6.1.2, but there aren't.
> > 
> > There ARE.  That is my point.  But I don't pretend this is obvious
> > to anyone assuming that wx works like other projects they are
> > familiar with.  And the fact that the 2.6 branch is in something
> > of a mess and some tags did not get applied when they should does
> > not make it any clearer.
> > 
> > wx does not release a 'one true source' tarball like lk and many
> > smaller projects do.  We support many disparate platforms, which
> > implies that for any particular platform, there is going to be
> > a lot of totally unrelated "cruft" in a 'whole source' tarball.
> > 
> > So we keep it all in cvs, tag the files linked to any particular
> > release, and than crank out a set of more specifically focussed
> > source releases.  This way debian users don't get affected when
> > the OS/2 developers (to pick a random example) find a critical
> > bug that requires them to re-release immediately.  But it does
> > mean we are not always exactly in sync with them.
> 
> You don't have to upload a new Debian package when an OS/2 bug was 
> fixed.

Nor do I need to even distribute the source for it...  There are
other places for that.

> But I'd e.g. expect what was packaged as "2.6.0" being the official
> wxWidgets 2.6.0 tarball plus some Debian packaging and perhaps some 
> fixes.

It just doesn't work that way.  Not if you want bugs fixed and
timely and functional uploads.  An 'official' release involves
getting many otherwise unrelated people all getting their shit
together on the same day.  In practice, that happens at most
a couple of times a year, and the releases are almost invariably
_more_ buggy than the snapshots from a week or so prior.  A couple
of weeks after that, the various platform dependent errata all
shakes out, and the platforms that need to release again.  All
the other 'officials' typically do not, being already busy with
other things again...

I don't say I espouse it as something to work towards, but it
is what we have to work with...

I make releases for Debian to suit the needs of Debian users,
that doesn't always match the needs of other upstream developers.
2.6 was released prematurely to coincide with a publishing deadline
for a book, so we've been riding on the occasional sane snapshot
for a while now.  Sometimes we have to grab them when we can.
Typically I tag them.  But they are as 'official' and 'upstream'
as anything else we distribute.

The official upload site of the official tar.gz made for Debian
platforms just happens to be d.o.  Trying to keep myself at arms
length from myself is not always the sane thing to do.

> > So you may not (and indeed in this case, will not) find alternative
> > source packages using the same release number.  They are released
> > with 'between' version numbers precisely to indicate that they are
> > not the result of a fully synchronised release on all platforms,
> > but rather contain errata of interest to the platform(s) they
> > were released for.
> > 
> > We almost always run on some such minor release, as wxPython
> > inevitably finds bugs in its testing phase after the C++ libs
> > are tagged for release.
> 
> It's common for many packages to sometimes package cvs snapshots, but 
> that's not a reason for a native packaging.

I'm not packaging cvs snapshots though, I'm making upstream releases.

> > The Debian source however is always generated directly from my
> > cvs working directory -- no changes are ever made outside that
> > scope, so it strictly tracks changes that have or will be made
> > upstream.
> 
> Your "cvs working directory" contains upstream sources plus your Debian 
> packaging.
> 
> Many other debian developers do their work in an upstream or local cvs 
> or Subversion repository, but that's not a reason for a native 
> packaging.

I'm not arguing that this package is somehow 'native'.  I'm simply
stating the fact that every release _I_ make (and this does not
apply to the package generally) is preceded by a numbered and tagged
upstream release.  The source from that release (not coincidentally)
is in a perfect form to be built by debian packaging tools, without
modification.

Give me a way to indicate this package is not 'native', but has
no changes to its pristine upstream state, and I will use it.
But I will not, for the love of reason, engage in farcical
acrobatics whereby I copy the entire source tree to a duplicate
location, only to produce a zero length diff after long consideration
of the contents of both copies.  That is just wasteful madness.
(though I have some other colourful phrases that might also apply ;)

Hard cases make bad law.  This is a hard case and I'm not seeking
to extend any generalisations from my decisions.  But I think they
are as right as I can make them given the tools at my disposal
and the real particulars of the situation.  I will continue to make
them better as other things improve, but I'll argue strongly they
should not regress for no advantage.

> > If we ever make an 'official' release that isn't instantly
> > broken in some way, you'll see a lot fewer diffs between
> > the different source tarballs...  but these releases are no
> > less 'upstream' just because they are uploaded to ftp.d.o
> > than they would be if they were also uploaded (much less usefully)
> > to ftp.sf.net or similar as well.
> > 
> > The handle was turned on cvs.  A numbered release popped out.
> > It was uploaded to the usual distribution site.  No Debian specific
> > changes were made between there and the end users.  Other distributors
> > may or may not release from the same tag.
> 
> This still doesn't make it "a piece of software was written specifically 
> to be turned into a Debian package".

I've already said I do not claim that.  It is a numbered upstream
release nonetheless.  Which requires no changes to build.  How
does that quotation help find a good technical solution?

> > > > If the package is uploaded with a real diff.gz then it should
> > > > have a debian version -- since it typically is not, the tools
> > > > dictate it should not have one.  That is the real bug, if any,
> > > > here.  I'm not sure who is interested in addressing it (this
> > > > isn't new), but there is nothing 'broken' to 'fix' at this end
> > > > that cannot be fixed more thoroughly and permanently in other
> > > > places.
> > > >...
> > > 
> > > It would be correct even if .diff.gz was empty, but as I explained above 
> > > your assumption your .diff.gz would be empty is wrong.
> > 
> > If we are going to argue this, lets not assume I'm naively
> > unaware of the Right Thing to do according to policy and
> > best practice, or didn't think through what I did do.
> > wx is weird in a number of ways and frustrating in a fair
> > number of others.
> > 
> > I think the current packaging best reflects the nature of the
> > source it is created from, within the technical constraints
> > of the tools.  I agree that overloading the social idea of
> > a 'native' package with the technical issue of 'no diff.gz'
> > clouds the real issue of why this package is like it is, and
> > why it perhaps should be different in a perfect world.
> 
> What's so extremely imperfect on an empty .diff.gz?
> 
> Especially considering that it can't be empty when you package an 
> upstream version whose official tarball does not contain a debian/ 
> directory?

See above.  Let's not go round and round on that one.

> > I'm not trying to indicate this is a package exclusive to
> > Debian, but the tools assume this if no Debian specific
> > changes are actually made.  If we are going to push the
> > tightest interpretation of what is a 'native' package,
> > then we need a better way to indicate that a wholly pristine
> > upstream source has been uploaded, for something which also
> > has uses outside of Debian, but supports it without need for
> > any change.  (clearly the latter is an optimum if uncommon
> > situation, despite the feeling of some developers re the
> > debian/ that _their_ upstream source supplies, but I cannot
> > help that ;-)
> 
> The tools do not assume that a package was native if no Debian specific 
> changes are actually made.
> 
> The tools assume a package was native if the maintainer forgot to put an 
> .orig.tar.gz at the expected place...

But they will not build it from the .orig/ so an identical copy
must be made and verified to be identical.  ie.  a silly no-op
for no net gain.

> > The main reason I prefer not to keep this open, tagged wontfix,
> > is that these sort of things tend to become polling booths for
> > anyone with a spare minute and a me too.  In ways that are
> > rarely productive.
> > 
> > I might add a FAQ to the package, or a wiki entry somewhere,
> > that summarises the debate to date though.  I have no objection
> > to seeing the apparent 'conflict' here resolved, and invite
> > intelligent arguments as to how we might do it, but I must
> > reject the idea that policy (re)definitions of what is 'native'
> > take precedence over the fundamental reasons for having a
> > diff.gz in the first place where the two are in conflict.
> 
> I see neither any technical problem with an empty .diff.gz nor with 
> adding a Debian revision to the package version.
> 
> Many Debian developers are upstream of the packages they maintain, and 
> this has never been a problem.

And I respect that they each do what is best for the needs of
their particular circumstance.  That is not the problem.

> > The best hope I've seen so far is the possibility that the
> > tools may (now) support using separate upstream.tar.gz and
> > debian.tar.gz (with no diff.gz) -- in which case I can fairly
> > sensibly just crank two tarballs out of my working dir instead
> > of one.  An extra file to juggle is much less heinous than
> > an entire redundant source tree.
> 
> You can e.g. simply copy the debian/ subdir from your working dir to the 
> upstream working directory, and this directory will get into the 
> .diff.gz.
> 
> That's more or less how all non-native packages work, so where's the 
> problem?

My working dir _is_ the upstream working dir.  I am upstream.
I simply don't want to spend 5 minutes for every build uselessly
smoking up my hardware and my time for zero net gain.

These files are copied and tarred enough times already.  Why do
it more times for no tangible reward?  Its more than 15Mb unpacked.
That's a lot of data to double deal needlessly ...

 Ron

Send a report that this bug log contains spam.