Re: Big and not yet packaged Java dependencies
On Tue, Sep 15, 2009 at 10:04 PM, Giovanni Mascellani
<g.mascellani@gmail.com> wrote:
> Geogebra depends, among the others on:
>
> 1. Jasymca, a CAS for Java[2]. There are two versions of Jasymca:
> Geogebra uses the old one, which has been included directly in Geogebra
> SVN and modified by Geogrebra authors. Is it acceptable to leave the
> embedded copy of Jasymca in Geogebra? The upstream version isn't
> maintained anymore (because Jasymca 2 has superseded it) and, anyway,
> couldn't be used in Geogebra.
It would be much better if Geogebra could migrate to the maintained
version of Jasymca and remove the embedded code copy. I would strongly
suggest Geogrebra can wait until you have worked with upstream to get
the embedded code copies removed before putting it in Debian.
> 2. FreeHEP, a Java library used in High Energy Physics[3]. A FreeHEP
> stripped copy is also included in Geogebra SVN. FreeHEP is not yet
> packaged in Debian (it has been ITP since January, but the bug, despite
> questions, doesn't contain info about its current status) and it is a
> really huge library. I don't think I would be able to package and
> maintain it: is it acceptable for me to leave the FreeHEP embedded copy
> in Geogebra until FreeHEP itself gets packaged, and then drop the
> embedded copy in order to use the packaged one?
Same as above.
> 3. Mathpiper, part of the Mathrider suite, another numeric and symbolic
> calculator. The same issues concerning FreeHEP apply: it is quite a big
> piece of software, for which I can't find any WNPP bug. Am I necessarily
> required to package it, or can I keep it as an embedded copy until
> someone else (or maybe also me, if at some point in the future I'll have
> time) packages it independently?
Same as above.
> Moreover, another little question: Geogebra is distributed under GPL-2+
> license for the code part, but translation strings are distributed under
> CC-BY-NC-ND 3.0 (and thus are non-free). Anyway, Geogebra is usable also
> without translation strings (of course, it is not internationalized, but
> misses no features). My idea is to package as two different source
> packages geogebra (all but translations) and geogebra-data
> (translations), being the first in main and the second in non-free.
> Moreover, geogebra would suggest geogebra-data: is this a good solution?
I would suggest geogebra-l10n unless there is more than just
translations. Otherwise, that is the right way to do things.
If you end up packaging Geogebra despite the above issues, please be
sure to file bugs on your package (blocked by the appropriate WNPP
bugs) about them and get the packages added to the security team's
embedded-code-copies file.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: