Debian Bug report logs - #351626
wxwidgets2.6 should not be native

Toggle useless messages

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

From: "Christoph Berg" <cb@intertalk.cs.uni-sb.de>

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

Subject: wxwidgets2.6 should not be native

Date: Mon, 6 Feb 2006 10:31:34 +0100

Package: wxwidgets2.6
Severity: important
Version: 2.6.1.2

Hi,

when backporting wxwidgets2.6 for sarge (as needed by amule), I
noticed that the package is native. Policy doesn't specifically
disallow that style, but imho it shouldn't be used for any non-trivial
package. Additionally, this makes NMUs/backports require a new
tarball, and leeds to ugly version numbers like "2.6.1.1bpo1". 

Please repackage wxwidgets2.6 (and wxwindows2.4) using a .diff.gz.

Christoph
-- 
cb@cs.uni-sb.de | http://www.df7cb.de/cs/
Universität des Saarlandes, Compiler Design Lab

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

From: Ron <ron@debian.org>

To: Christoph Berg <cb@intertalk.cs.uni-sb.de>, 351626-done@bugs.debian.org

Subject: Re: Bug#351626: wxwidgets2.6 should not be native

Date: Mon, 6 Feb 2006 21:59:15 +1030

On Mon, Feb 06, 2006 at 10:31:34AM +0100, Christoph Berg wrote:
> when backporting wxwidgets2.6 for sarge (as needed by amule), I
> noticed that the package is native.

This is not accidental and has been explained and debated many
times.  Answer:  there is no diff.gz.  Or bug.

> Policy doesn't specifically disallow that style,

Precisely.  Our predecessors were wise.  Though opinions like this
have tried repeatedly to encroach on that.  Without ever caring to
address the real issue:  There is no diff.gz.

If you do something that means it should have one, then you
should package your changes appropriately.  As I do.

Wilful misinterpretation of policy to take a more narrow view
than it actually proffers does not make an "important" bug out
of a non-existent one.

> but imho it shouldn't be used for any non-trivial package.

That is a completely spurious and intractable line of reasoning.
Here's a simpler one:  Packages with a diff.gz should have a
corresponding Debian version for each published diff.

Note how it doesn't require arbitrary policy or humble opinions.
Just a simple technical test.

All this talk of "native" is emotive and does not represent any
real problem we have to solve.  What is important is people know
what source they are getting.  In this case, pristine upstream,
straight from cvs.

I can't think of a more trivial package than unchanged pristine
upstream source, can you?  Or do you have a different definition
of 'non-trivial'?

Everything is non-trivial if you do it wrong.

> Additionally, this makes NMUs/backports require a new
> tarball, and leeds to ugly version numbers like "2.6.1.1bpo1". 

If you change something that is not a part of the upstream release
then of course you will need to make an orig.gz and add a diff.gz
for your changes.  _You_ should NEVER use version numbers like the
above at all -- they are the domain of upstream (for these purposes
read 'me' with a different hat on) to use when making releases.
If you mess about like that, you may need to repackage an official
release with an epoch for your users to see it as an 'upgrade'.
And that would be your problem.  Don't file a bug asking me to add
one...

If you do an _NMU_ like that without consulting me, _I_ will be your,
very vocal, problem...  :-)  Don't do that ok.  If this package looks
non-trivial to you, talk to me before uploading anything that I am
ultimately responsible for.

If you make local changes, you should add a diff.gz like the
developers reference tells you to.  Don't misinterpret what I have
done as justification for doing something wrong yourself elsewhere.

If _you_ don't provide a diff.gz, then how else am _I_ supposed to
know what you have done, to see if I want to integrate it upstream
(though of course in the good 'ol days, you'd have actually been in
contact with upstream and would be passing such things on...  I
wouldn't have to come look for it at all...).

If you'd ever talked to me before (see the relevant chapters on
collaborating with your upstream), you wouldn't be wasting my
time with this pointless re-run either.  See the benefits?

I don't mean to sound (too) snappy, but you are not the first...
I'm still hoping to live to see the last.

> Please repackage wxwidgets2.6 (and wxwindows2.4) using a .diff.gz.

What exactly would you have me fake up to put in it?

You should definitely do this if you ever have something that should
go in one, but I do not.  All my changes go 'upstream' first, then
Debian distributes a new upstream release.

Policy may be distorted to created a more bigoted definition of what
is "native", but this package will not ship from me with an empty
diff.gz before the tech-ctte completely loses its grip on reality.

If you see a problem here, fix the terminology, and in particular
stop using a heavily overloaded and deliberately vague notion of
"native", to address the technical problem of a package that we
have made no changes to at all.

wx was not written for Debian.  Nobody in their right mind who
knew what it was would think that.  But that is irrelevant here.
There is no diff.gz.  That is all that matters,  Spread the word.

thanks!
Ron

Send a report that this bug log contains spam.