Hi Kili,
On 06/17/16 01:32, Matthias Kilian wrote:
> Hi,
>
> On Thu, Jun 16, 2016 at 05:34:09PM -0500, Aaron Poffenberger wrote:
>> Thanks to your suggestion and a pointer to the Java "maven" thread by
>> Ian Darwin, I've updated the patches to ghc.port.mk to include fetching
>> the cabal dependencies using DISTFILES.
>>
>> I tested building pandoc with networking disabled. It works.
>
> I don't think this cabal sandbox model is suitable for ports in any
> way. What will happen if we enable shared libraries for ghc (which,
> according to some mails from Karel Gardas, should be possible with
> ghc-8)? Where will those libraries be end up in ${LOCALBASE}?
For the most part, the value of sandboxing the build will be to build
stand-alone executables like pandoc. Once built, the bits from
MODGHC_CABAL_SANDBOX aren't further referenced and may be safely deleted.
>
> And do you think it's useful to have several different versions of
> the same haskell library sprinkled over the system?
>
> In the pandoc port, MODGHC_CABAL_PKGS even contains library/version
> combinations we already have as separate ports.
The point of specifying the versions is those are the exact combination
of pkgs the cabal resolver determined will work together based on the
constraints from the pandoc.cabal file *and* the libraries I required in
RUN_DEPENDS-lib.
The versions are also required since BULK(8) builds don't allow network
access. As I understand it, everything has to be downloaded into
FULLDISTDIR before configure begins.
>
> Sorry, but I'm not a big fan of this concept.
>
> BTW, the pandoc-lib subpackage doesn't make any sense unless it
> does not depend on any of the cabal packages listed in MODGHC_CABAL_PKGS,
> because the libraries provided by those packages would be missing
> (they aren't installed). It also wouldn't install properly because
> PLIST-lib is wrong.
You're right about the -lib pkg. It won't work as currently ported. The
chief aim of sandboxing was to make standalone binaries possible without
a recursive porting effort for all the dependencies.
There are three possible resolutions: 1) don't include the -lib in the
package, 2) install the dependencies in
${LOCALBASE}/lib/ghc/pandoc-1.17.1 and update register.sh, or 3) scrap
the sandboxing idea altogether.
I don't like the last idea: scrapping sandboxing. pandoc has huge, unmet
dependency lists. And even if one were to recursively port every missing
dependency we still might have conflicts with existing ports due to
version-requirement conflicts. This would lead to having the same pkg
ported twice but for different versions.
I'm sure you know this is why Haskell-LTS was started: to create a
stable list of pkgs that work together. Unless we're following a
specific LTS release, we will run into version conflicts at some point.
(I think following a specific LTS release would be a good idea, but
that's a conversation for another email.)
Sandboxing solves this problem, certainly for binaries. And could
resolve library conflicts if libs can have their unmet dependencies
installed in their ${LOCALBASE}/lib/pkg dir.
Cheers,
--Aaron
