On 15 Nov 2010, at 13:06, Charles Lepple wrote:

> On Nov 14, 2010, at 11:57 PM, David Fang wrote:
>
>> There isn't anything we can do about Apple's decision, unfortunately.
>> Unless you actually intend to use the java interface for ppl, it
>> shouldn't
>> be an issue if this package drops the Java module in the future.
>
> I haven't checked to see if any Fink packages use the Java module, but
> Fink's dependency engine seems to be better about handling cases where
> a single .info file with splitoffs is converted into two or more .info
> files (carve-offs?), each with a reduced set of BuildDepends.
>
> This way, the base ppl package wouldn't need to depend on Java, but
> there would still be a Java option if someone has installed all the
> external dependencies. The nice thing for end users is that if it's
> the same source file, they most likely already have it in /sw/src (and
> they won't need to re-download it for the Java carve-off).
>
> Barring any general objections from the list, let me know if you want
> help testing something like that. I could probably remove the Java
> headers from one of my machines here and not run into any other
> problems outside Fink.


There are a bunch of problems of that sort with ppl, and it is probably
best to address all of them at once.

1) The package builds differently according to the presence or not of  
other
fink pkgs. From old notes, and from memory, this includes glpk and  
most prolog
pkgs (gprolog, swi-prolog, yap), ocaml and possibly some other ocaml- 
related pkgs
(ocaml-lib and/or ocaml-findlib)..
Depending to the specific versions of ppl itself and/or the above fink  
pkgs
and/or the fink installation there may be one or other of the above  
that fails,
but the above is the typical picture of what the pkg tries to do..
And there may be 1 or 2 of the above that are only triggered by  
additional
configure params, but for most this is not the case.

2) As the above shows, this is a pkg intended for a "prolog-type  
audience",
(part of the) OR theory community, and the like; and belongs to the  
section "sci".
It is most basically and originally an exact implementation of Fourier- 
Motzkin as I remember,
plus more generally of mixed linear programming, and a bit more.
All such pkgs are in the section "sci", and (a full version of) ppl  
belongs there too.

3) Such a full version should probably be essentially fully enabled,
if only to respect the upstream intent ("upstream knows better").
On the other hand, it is not reasonalbe to let gccXY have such a list of
dependencies. This would call for a varianted pkg, with a "mini" variant
providing just what the gccXY pkgs actually need, and taking great  
care to build
identically even if any of the above fink pkgs (or other conceivably  
relevant
local pkgs) are installed.

4) In other not to disrupt existing pkgs, it might be more convenient  
to call
the "mini" variant "ppl", and the full variant "ppl-full" or "ppl-max",
that would Provide "ppl", waiting for the next update of gccXY to depend
on the alternative (so that versioned depends can be used if necessary).

I don't think it is reasonable to aim for further varianting : users  
who are
interested in ppl per se, rather than just as a step to build gcc, can  
bear
the cost of building one or other interface that interests them less..

Jean-Francois Mertens

PS : The "full" variant is for users who want ppl per se; I like to  
build it
with the latest gccXY, but this is an independent issue.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to