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 <[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.
> > 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
