Your message dated Thu, 22 Dec 2005 14:50:07 +1030
with message-id <[EMAIL PROTECTED]>
and subject line Bug#344280: wxwidgets2.6 is not a native Debian package
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 21 Dec 2005 14:28:30 +0000
>From [EMAIL PROTECTED] Wed Dec 21 06:28:30 2005
Return-path: <[EMAIL PROTECTED]>
Received: from emailhub.stusta.mhn.de ([141.84.69.5] helo=mailout.stusta.mhn.de)
by spohr.debian.org with smtp (Exim 4.50)
id 1Ep4xC-0000x1-5j
for [EMAIL PROTECTED]; Wed, 21 Dec 2005 06:28:30 -0800
Received: (qmail 7756 invoked from network); 21 Dec 2005 14:27:59 -0000
Received: from r063144.stusta.swh.mhn.de (10.150.63.144)
by mailhub.stusta.mhn.de with SMTP; 21 Dec 2005 14:27:59 -0000
Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000)
id 374CD34A4E; Wed, 21 Dec 2005 15:27:59 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Adrian Bunk <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: wxwidgets2.6 is not a native Debian package
Message-ID: <[EMAIL PROTECTED]>
X-Mailer: reportbug 3.18
Date: Wed, 21 Dec 2005 15:27:59 +0100
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
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.
---------------------------------------
Received: (at 344280-done) by bugs.debian.org; 22 Dec 2005 04:21:06 +0000
>From [EMAIL PROTECTED] Wed Dec 21 20:21:04 2005
Return-path: <[EMAIL PROTECTED]>
Received: from ppp213-196.lns1.adl2.internode.on.net ([203.122.213.196]
helo=hank.shelbyville.oz)
by spohr.debian.org with esmtp (Exim 4.50)
id 1EpHwp-0000tN-Lx
for [EMAIL PROTECTED]; Wed, 21 Dec 2005 20:21:01 -0800
Received: from ron by hank.shelbyville.oz with local (Exim 4.60)
(envelope-from <[EMAIL PROTECTED]>)
id 1EpHvz-0007cC-G1; Thu, 22 Dec 2005 14:50:07 +1030
Date: Thu, 22 Dec 2005 14:50:07 +1030
To: Adrian Bunk <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Bug#344280: wxwidgets2.6 is not a native Debian package
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.11
From: Ron <[EMAIL PROTECTED]>
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-2.5 required=4.0 tests=HAS_BUG_NUMBER,RCVD_IN_SORBS
autolearn=no version=2.60-bugs.debian.org_2005_01_02
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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
