New subject: Listing native package requirements based on cabal information

18 Mar 2014

      On Wed, Mar 19, 2014 at 10:15:08AM +1300, Chris Wong wrote:
...
On Wed, Mar 19, 2014 at 9:47 AM, Tobias Dammers  wrote:
...
Hmm, but then, not all package managers/repositories use the same names
for packages. So even if there were a way to extract the required
libraries from cabal, feeding that information to the package manager
isn't going to be trivial at all.
It's not trivial, but I don't think it's difficult.
For example, Debian Haskell packages all take the form
libghc-NAME-dev. Fedora uses haskell-NAME. Sure, there's a bit of hard
coding involved, but the set of prominent distributions is finite.
I think installing *haskell* packages is not the problem; cabal already
does a decent job at that. The problem we're facing is that cabal can
*only* install haskell packages, but not any of the native libraries
they depend on (usually through FFI, but other examples exist, such as
the pg_config tool from PostgreSQL).

Besides naming convention issues (which could be compensated for with
lookup dictionaries; a brute-force solution, sure, but better than
nothing), a bigger problem is that sometimes packages don't match 1:1
between distros, so one distro might just provide one monolithic
foobar-dev package, while another might split it up into
foobar-client-dev and foobar-server-dev, while yet another might provide
more than one alternative.

TL;DR: I think if we could just get a list of required native packages,
we'd be a long way.
...
One problem, though, would be versions. I know we often ask for the
latest and greatest packages, which may conflict with what the
distribution supplies. So the benefits may not be as high as they
seem.
By the way -- has anyone looked into 0install? It hashes things,
similarly to Nix, but also tries to integrate with the existing
package manager. For example, if the user wishes to install GHC 7.6,
but the Debian repositories already supply it, it will invoke apt-get
instead of installing on its own.
...
(And frankly, looking at build systems
for other languages, I've never seen anything that does this - even
autotools doesn't really do a lot more than check whether a library is
available).
That said, even if we could just get a list of required libraries out of
cabal, in a somewhat human and machine readable format, that would be a
huge win in itself.
On Tue, Mar 18, 2014 at 11:48:33AM -0700, David Thomas wrote:
...
One option that just occurred to me would be to allow passing a script to
cabal that could be passed the extra-libraries (if any), and could install
if it knew the relevant OS packages (or NIX packages), or abort with a
cleaner error message.
Actually, wrapping ghc might be sufficient (though not ideal).
On Tue, Mar 18, 2014 at 11:29 AM, Michal Antkiewicz <
mantkiew@gsd.uwaterloo.ca> wrote:
...
This is not an immediate solution but I can imagine listing NIX packages
as dependencies inside a cabal file, then NIX would create a sandbox with
these dependencies and cabal would build in that sandbox. The advantages
are that you're not messing around with the underlying operating system's
packages, NIX handles all dependencies transitively, and everything is
specified declaratively. Sounds like a nice GSoC project :-)  You could
also do cross GHC version's builds as GHC itself can be sandboxed. Quite
intriguing.
Michal
On Tue, Mar 18, 2014 at 2:16 PM, Michal Antkiewicz <
mantkiew@gsd.uwaterloo.ca> wrote:
...
Certainly NIX is an interesting approach. It already comes with a large
base of dependencies, a format for specifying them. NIX can be installed in
any Linux distro and serve as an environment for building packages. That
might provide a cross-distribution solution to the native dependency
problem.
See, a nice post by Oliver Charles
http://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html
Michal
On Tue, Mar 18, 2014 at 1:59 PM, David Thomas wrote:
...
Ok, well, if that's the case I'd like to see about remedying that.
Anyone have any thoughts as to how to best go about this?  I'm not clear on
exactly what info lives where, especially across systems.  Entirely manual
population would be a (barely) acceptable fallback.
On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton wrote:
> I have wished for this on multiple occasions. I don't believe such a
> thing exists as of yet.
>
> -- Dan Burton
>
>
> On Tue, Mar 18, 2014 at 9:26 AM, David Thomas  > wrote:
>
>> Is there a way to extract this?  I'm looking to make it easier for
>> newcomers to my project to get things building across different linux
>> distros.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Listing native package requirements based on cabal information

Tobias Dammers

Dan Burton

mantkiew＠gsd.uwaterloo.ca

Chris Warburton

tags

participants (4)