February 2011 - cabal-devel

patch applied (cabal-branches/cabal-1.10): "Fix HcPkg.dump for the case of an empty database"
by Duncan Coutts 10 Feb '11

10 Feb '11

Thu Feb 10 12:01:11 PST 2011 Duncan Coutts <duncan(a)community.haskell.org> * Fix HcPkg.dump for the case of an empty database Previously it returned the value [emptyInstalledPackageInfo] M ./Distribution/Simple/Program/HcPkg.hs -1 +7 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-branches/cabal-1.10;a…

1 0

patch applied (cabal): "Fix HcPkg.dump for the case of an empty database" and 1 others
by Duncan Coutts 10 Feb '11

10 Feb '11

Thu Feb 10 12:01:11 PST 2011 Duncan Coutts <duncan(a)community.haskell.org> * Fix HcPkg.dump for the case of an empty database Previously it returned the value [emptyInstalledPackageInfo] M ./Distribution/Simple/Program/HcPkg.hs -1 +7 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=… Thu Feb 10 12:06:03 PST 2011 Duncan Coutts <duncan(a)community.haskell.org> * Always use verbosity slient when calling hc-pkg dump We don't want to contaminate the hc-pkg output with info/debug messages. Coincidentally the messages that current ghc-pkg versions produce at -v2 verbosity level do not cause a problem. There's no reason to expect future versions to work that way however. M ./Distribution/Simple/Program/HcPkg.hs -2 +4 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

Re: [Haskell-cafe] [Cabal-devel] Cabal && license combinations
by Duncan Coutts 10 Feb '11

10 Feb '11

On Thu, 2011-02-10 at 12:44 +0100, Stefan Kersten wrote: > On 10.02.11 12:12, Duncan Coutts wrote: > > We are already working on a feature that will show the full set of > > licenses that the end user must comply with (a patch has been submitted > > and it's been through one round of review so far). In your example that > > would mean you expect the set to be {BSD} but the tool will show you > > that it is in fact {BSD, GPL}. You can then use that as your warning > > that the set of licenses is not what you expected. > > that would be quite useful for those who want to distribute executables! > > may i also suggest the following feature: collect all the copyright notices and > license files from each dependency (many licenses require those to be displayed > and distributed along with the executable) and optionally bundle them with the > applicaton's data-files? i briefly looked into this, but couldn't find a way to > retrieve the installed License-File from ~/.cabal using Cabal. doing this by > hand turns out to be quite tedious when there are many dependencies ... Right, that feature was also in the patch. From experience I know that this would indeed be very useful (I've also had to do it manually). Duncan

1 0

[Haskell-cafe][Cabal-devel] Cabal && license combinations
by Dan Knapp 10 Feb '11

10 Feb '11

I haven't heard anyone mention this yet, and it's a biggie, so I guess I'd better de-lurk and explain it. The issue is this: There is a legal distinction between static and dynamic linking, or at least some licenses (the GPL is the one I'm aware of) believe that there is. In particular, they assert that you are legally creating a "derived work" if you statically link with their library, and that your library, even if it's just a thin bindings wrapper, must therefore comply by their license terms. They make no such claim for dynamic linking. Of course, Haskell on most platforms and default configurations links everything statically! So I believe this means that you have to comply by the licenses of all your dependencies! Now, there's a difference between complying by those licenses and being under them yourself, but for example I believe this means that if we have a package named "hs-save-the-whales" that is under the GPL, and a front-end package "hs-redeem-them-for-valuable-cash-prizes" which makes use of the functionality in hs-save-the-whales, the front-end MUST be offered under the GPL, and, additionally, CANNOT be offered under BSD (I think). I think it would be a very useful and valuable thing for Cabal to detect this situation and warn appropriately! Contamination by undesired licenses is a serious flaw in the packaging of a package; it just happens to be a legal flaw rather than a technical one. Indeed, I would argue that this is far more important than any hypothetical per-file licensing. -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

2 1

Re: Cabal && license combinations
by Vivian McPhail 10 Feb '11

10 Feb '11

> On Mon, 2011-02-07 at 14:42 +0000, Malcolm Wallace wrote: > > > It seems then that a package should be the least restrictive > > > combination of all the licenses in all the contained modules. > > > > Omit the words "least restrictive" and I think you are correct. > OK. > > > > To combine licences, just aggregate them. There is no lattice of > > subsumption; no "more" or "less" restrictive ordering. It's simple: > > you must obey all of them. Some aggregations introduce a > > contradiction of terms, so you cannot legally aggregate those modules > > without breaking some term. But if the terms of the aggregated > > licences are compatible rather than contradictory, then all is good. > > Right, so the effect of per-file/mixed licenses could be achieved by > letting packages specify a list of licenses: > > license: Foo, Bar > Could this be computed automatically from the source files by Cabal? > > Meaning you may copy/distribute provided you comply with all these > licenses. > > Note that this does not cover dual licensing, e.g. Foo or Bar at > distributor's choice. > > Duncan > Looking specifically at hmatrix, there are three kinds of modules i) bindings to GSL GPL ii) bindings to LAPACK BSD iii) pure Haskell hmatrix author's choice 1) Am I correct in thinking that even the bindings modules (the Haskell parts, not the C files) can be under any licence, FOO, chosen by the author, but the binary _linked_ to, say, GSL has to comply with FOO and GPL? 2) If someone uses hmatrix but no GSL functions (hence there are no GSL functions in the linked binary) can they get away with not complying with the GSL requirement? Cheers, Vivian

2 1

Cabal && license combinations
by Vivian McPhail 08 Feb '11

08 Feb '11

Dear All, There was recently a discussion on haskell-cafe ( http://www.mail-archive.com/haskell-cafe@haskell.org/msg86472.html) about licenses of libraries such as hmatrix and the combination of various different licences. One question was about per-package versus by-file licenses: In Haskell the compilation unit is the module, and the per-file cabal header allows for a license field. It seems then that a package should be the least restrictive combination of all the licenses in all the contained modules. If this has to become a hand-coded fancy function of various GPLx, BSDy, OpenSource, and other licenses then so be it. That is the legal reality. And use of a BSD3 module in hmatrix that does not depend upon GPL'd GSL modules would be acceptable. In short, I argue for a per-file(module) license regime. Vivian

3 2

Re: [Hackage] #600: Cabal should have an option to dynamically link executables
by Hackage 03 Feb '11

03 Feb '11

#600: Cabal should have an option to dynamically link executables ----------------------------------+----------------------------------------- Reporter: juhp | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.10 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.12.3 Platform: Linux | ----------------------------------+----------------------------------------- Comment(by juhp): Thanks, Duncan for applying the patch to HEAD. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/600#comment:18> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: cabal-install comment typo
by Jens Petersen 01 Feb '11

01 Feb '11

On 1 February 2011 20:23, Duncan Coutts <duncan(a)community.haskell.org> wrote: > On Sun, 2011-01-30 at 21:09 +1000, Jens Petersen wrote: >> Great, thanks. (I already put it into Fedora's development tree >> since I got tired of binlib packages not getting dynamically linked...:) > > Ok, so my next question is whether this is critical for the next 1.10.x > release or whether we can let it sit in head for a bit. I don't think > any other platforms are yet doing full dynamically linked builds. For > most users, doing --enable-dynamic is going to fail because all the > dependent libs are not build dynamically (much like the problem people > have with profiling libs not being tracked). Well I was wondering the same... Of course it would be nice to see it in some 1.10.x release, but if it is only needed by Fedora then we can probably carry it as a patch for now. I am not sure if all the potential code paths have been tested, though so far it "worksforme". Anyway it is probably sensible to leave it for ghc-7.0.3 or later at this point. :) (For my next trick I want to teach ghc to be able to live without static libraries (so that --disable-library-vanilla will actually be useful): I think that it still doesn't like missing static libs?) > Thanks. Applied to head for now. :-) Thanks, Jens

1 0

patch applied (cabal): "add --enable-executable-dynamic option for dynamic linking of executables"
by Duncan Coutts 01 Feb '11

01 Feb '11

Sun Jan 30 03:02:06 PST 2011 Jens Petersen <juhp(a)community.haskell.org> * add --enable-executable-dynamic option for dynamic linking of executables M ./Distribution/Simple/Configure.hs +1 M ./Distribution/Simple/GHC.hs -6 +11 M ./Distribution/Simple/LocalBuildInfo.hs +1 M ./Distribution/Simple/Setup.hs +10 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

"Cabal ignores ld-options?" - 2011 remix
by Ryan Newton 01 Feb '11

01 Feb '11

Oops, sent this to Cafe but it's more appropriate for cabal-devel. ---------- Forwarded message ---------- From: Ryan Newton <rrnewton(a)gmail.com> Date: Sun, Jan 30, 2011 at 4:54 AM Subject: "Cabal ignores ld-options?" - 2011 remix To: Haskell Cafe <haskell-cafe(a)haskell.org> Hi cafe, I am trying to link a ".a" file built by a separate makefile into my library. GHC has no problem with it, but I need to convince cabal to do it for the package to be hackage-friendly. There's a thread about this back in 2007: http://www.haskell.org/pipermail/cabal-devel/2007-April/000507.html Is there a method for this now, or is the state of affairs the same as before? Thanks, -Ryan

2 7