Hi Ron,

thanks for the prompt response!

On Saturday 01 December 2007 04:37, Ron wrote:
> The problem at present is not that there is any fundamental
> opposition to including them in the package, but rather that
> people did the work to make that possible, then upstream
> refused to include it.

from what I have understood, 
this was the "big" solution which upstream refused
or just did not show interest in.
I propose to go for a "medium" or "small" solution first.

> So I'm not really sure what we can do about that, especially
> if even the people who need it find it preferable to use a
> local hack than to spend the time to fix it properly ...

If you refer this to the Thuban developers (which I am a part of),
there are many sensible and practical reasons to have a "local hack"
first. One is timing: We need to deploy on Etch as well.
So our strategy is to have something quick and then help to solve
the problem in a better way for the long run.
And we are investing _some_ time, as you can see by me responding to this 
issues, but note: we are depending on a fair number of upstream packages,
for many we have suboptimal solutions and we cannot fix this at the root
all the times as this would leave us with no time for our application as well.

> But given that 2.8 is still a moving target and will likely
> be obsoleted by 3.x before its problems are fixed, and that
> neither of those things may happen in time for the Lenny
> freeze, I am willing to listen to proposals and consider
> patches from people who seriously want to look into this
> again and have the time to implement and test it properly.

Some suggested that a simple change in the Debian build files
could make this file be installed. This seems a small solution
given that upstream is less interested. 
In parallel we should bring the issue up with upstream again.

> I don't want to just move the 'fragile hack' from one
> package to another though, so this is going to require
> some genuine commitment from the people who need it to
> get it right and fix any trouble that shakes out.

The small solution seems to be easy enough to port if wxPython changes,
so it is less fragile then hack to the setup.py structure in Debian.
It is possible to use "get it right" as blocker, 
but it also can make Debian less attractive.

My time for Thuban development currently is very limited,
so I just cannot look very deep into the problem. 
Your situation might be the same, but we share the same goal,
making the wxPython package and thus Debian more attractive.
Thanks for all the work you have done on this package!

Best Regards,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Attachment: pgperzDDTsitz.pgp
Description: PGP signature

Reply via email to