cvs commit: ports/java/jgraphx Makefile distinfo

Chris Rees utisoft at gmail.com
Sun Aug 29 10:23:43 UTC 2010


On 29 August 2010 01:11, Rob Farmer <rfarmer at predatorlabs.net> wrote:
> On Sat, Aug 28, 2010 at 2:28 AM, Chris Rees <utisoft at gmail.com> wrote:
>> 2010/8/27 Alexey Dokuchaev <danfe at freebsd.org>:
>>> On Thu, Aug 26, 2010 at 09:53:32PM -0700, Rob Farmer wrote:
>>>> This breaks math/scilab (which is the only dependency in the ports
>>>> tree). Unfortunately, the author of jgraphx seems to completely
>>>> disregard backwards compatibility and changes the API in virtually
>>>> every release.
>>>>
>>>> I tried to patch Scilab based on their git repository (which has
>>>> support for 1.4.0.1), but hundreds of revisions have passed and they
>>>> have rearranged their tree a bit and added/removed some files, so it
>>>> didn't go well.
>>>>
>>>> IMHO, we need to either create a separate jgraphx-scilab port or keep
>>>> this in sync with Scilab (this is what Debian, Ubuntu, and Gentoo are
>>>> doing).
>>>
>>> Considering Scilab is the only consumer of jgraphx, it seems having
>>> special port would be an overkill.  I think we should keep the two in
>>> sync, and probably work with upstream maintainers of both projects to
>>> improve compatibility and API inheritance in the future.  Separate port
>>> of jgraphx-scilab is palliative solution, i.e. it simply increases the
>>> entropy, not solving the underlying problem.
>>>
>>> ./danfe
>>
>>
>> Since Scilab is the only consumer of jgraphx, I don't mind reverting it.
>>
>> Actually, I wrote that while trying to repair Scilab myself, so if you
>> want maintainership of jgraphx too, that's fine.
>
> I don't want to feel like I'm stealing your ports, but I do think it
> would be a good idea to have them maintained together.
>
>>
>> Alternatively you could have it as another distfile in Scilab rather
>> than depending on the port....
>
> I hadn't thought about this, but it may actually be the best solution
> - as far as I'm aware, the reason for having libraries in separate
> ports is to allow multiple applications to use the same copy, but
> given the instability of the jgraphx API, I think it is unlikely that
> multiple ports could depend on one common version of jgraphx (at least
> without significant patching), so the benefits of having a jgraphx
> port are probably limited. Thoughts?
>

You're not stealing my ports, you'd be taking a logical step to fixing
the madness!

You are welcome to jgraphx if you want it, though having thought about
the instability, maybe the alternative distfile could be a good
solution. Have a look at the attached patch; the only thing i haven't
done is told configure it's not a problem that jgraphx.jar isn't there
yet...

Of course, jgraphx is still a useful port for people who want to use
it themselves in their own programming; there are plenty of other
ports that aren't depended on by anything else!

Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scilab.diff
Type: application/octet-stream
Size: 3012 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20100829/1c48d893/scilab.obj


More information about the cvs-all mailing list