Stefan,
On 02/01/2012 09:29 AM, Stephan Adig wrote:
thanks a lot for your afford. Just pass me the location of the package
and I'll have a look into it.
Mh, I cannot find it. I tried the package search on debian.org but
failed. The search only allows you to search backwards until Lenny, and
I have no idea if qooxdoo is supposed to be in Lenny or if it was only
in prior releases, or if in Lenny from what repo.
Here is a link to the initial (I believe) bug to bring qooxdoo into the
distribution:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485975
The guy working on it was Niko Tyni. One of the motivations to bring in
the package was Tobi Oetiker's "smokeping" app, which relies on qooxdoo,
so they would need it to re-build smokeping from source.
If you look at the bug it's from 2008, but I know that Tobi and Niko
were working on it also at later times (e.g. Tobi made a mailing list
posting in that regard on 06/2009).
@Tobi, can you chime in to give a more current account?!
Why I'm asking is, that actually it's not like the dojo or jquery
packages in Debian/Ubuntu.
Dojo e.g. does come normally with some binary helper packages to
provide the minimizing of the javascript library. So, the goal of the
package was to remove this dependency and use system libs coming from
Distribution packages.
I see, but still qooxdoo would be a lib too, right?!
What I would like to do is to remove eventual existing code
duplication (e.g. python libs which are already available as packages
and which are used by the qooxdoo python generation module) and get
everything to work.
I'm not sure this would be worth the effort, or would even work. For one
thing, the extra Python modules we are including are tiny, so there
wouldn't be much space wasted in having them even if there were
system-provided versions for them.
Then we e.g. use "ElementTree", which is in Python 2.5 as standard
module xml.etree.ElementTree, but the version we are using is newer than
the one in the standard lib, and is received from the author's
repository directly. Using the standard modul instead would in fact
break the generator code.
You could probably replace the "pyparsing" module we ship, but you would
then need to adapt the generator code individually, as we have renamed
the package to "pyparse", exactly for the reason that it doesn't clash
with a potentially globally installed pyparsing.
Then there is "polib", but our module contains patches that we have
applied. Replacing it with a standard polib would again most likely
break the generator.
And even if there were a globally installed module of the same name
(this could be the case e.g. with the "graph" module), within the
generator we're installing our own library path "tool/pylib" *in front*
of the Python search path for modules, so our own modules are always
found first.
So why would you go through all these efforts to replace third-party
modules in the SDK with their distribution counterparts, provided there
is any, when you have so many caveats and pitfalls?! For what benefit?
Also, people seemed to struggle with the Debian package for qooxdoo [1],
so the old efforts might not be successful in all cases.
If this gives rise to more conflicts I'd be interested to hear about them.
Keep us updated,
T.
[1] http://stackoverflow.com/questions/3808265/qooxdoo-and-debian-lenny
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
