Your message dated Thu, 22 Dec 2005 18:46:38 +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 10:44:07 +0000
>From [EMAIL PROTECTED] Thu Dec 22 02:44:07 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 1EpNvZ-0001bW-SE
for [EMAIL PROTECTED]; Thu, 22 Dec 2005 02:44:07 -0800
Received: from ron by hank.shelbyville.oz with local (Exim 4.60)
(envelope-from <[EMAIL PROTECTED]>)
id 1EpLcs-0000lJ-Eq; Thu, 22 Dec 2005 18:46:38 +1030
Date: Thu, 22 Dec 2005 18:46:38 +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]> <[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 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 <[EMAIL PROTECTED]> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
