On 30 jul 2007, at 17.00, Ian Lynagh wrote:

I've thought for a while that we should have a cabal-lint, that runs the sanity checks that hackage does before accepting an upload. Perhaps cabal-lint could also check that building and haddocking works, and run the packages testsuite too? People would then be encouraged to run that before uploading to hackage, and to the extent permitted by security concerns, hackage could run cabal-lint itself.

It should certainly be part of cabal-upload. (We do have a cabal- upload program, don't we?) / Thomas

On Sat, 2007-08-04 at 14:44 +0100, ross@soi.city.ac.uk wrote:

Quoting Duncan Coutts :

...

* haddock docs not building. This is very common. The most common parse problem is un-escaped / chars. This seems to trip people up a lot. I wonder if we could make haddock's parser grok this better? For example most uses of ' don't cause problems, eg "don't". I wonder if we could have a similar rule for / so that things like "I/O" didn't get recognised as beginning an emphasised section. Perhaps the rule should be that / but be at the beginning or end of a token, so a " / " or a "X/Y" would not count, only "/beginning" or "ends/" of words?

Like Ian, I'm not sure that complicating haddock is the way to go. It doesn't seem unreasonable to expect people to test build their packages, including with haddock, before making a release.

Simon is having a look at this issue. But yes, getting people to test would be good. We can do this with our tools, eg cabal-upload and/or a cabal lint command or something.

...

* inability to automatically find/generate dependencies on external packages like C libraries. Many packages that use FFI need to link to non-standard C libs and it's not always obvious what packages they need. Of course, specifying external libs is not simple since different platforms often call them different things, but perhaps we could have some non-binding hint fields. Or perhaps we should just try and guess based on the names of the libs that need to be linked to (though that doesn't cover deps on other programs rather than C libs).

This is a hard one, because the packages you need will vary between systems, e.g. between Debian and Gentoo, let alone Unix vs Windows. It may be necessary to have a little extra information for each system.

I'm not sure it's that hard. Distros have weirder naming conventions than upstream packages typically do. So we can target the upstream name and let distros map that to their package names in whatever way they can. So I'm not asking for a 100% sure mapping to system packages, but a reasonable hint. For example: pcre; the upstream project call it "pcre" and release pcre.-x.y.tar.gz packages. Gentoo calls it dev-libs/libpcre and debian calls it libpcre3 but that's their problem really. Just having this hint at least tells us that we have a dep we should try to satisfy by mapping it to some system package name. Not knowing of the dependency at all until the package fails to build is surely worse. Another example: darcs-graph depends on the gnuplot program at runtime. This one is a totally untracked dependency unlike the pcre example where we at least have the hint of pcre in the extra-libraries: field. Again, the name is not that ambiguous, it's sci-visualization/gnuplot on gentoo and gnuplot on debian. So getting this perfect is too hard, but having some useful information would really help in many situations, eg for hackage's auto-builder, cabal-install and generating distro packages from cabal packages. Duncan

On Sat, 2007-08-04 at 22:32 +0200, Henning Thielemann wrote:

On Mon, 30 Jul 2007, Duncan Coutts wrote:

...

* inability to automatically find/generate dependencies on external packages like C libraries. Many packages that use FFI need to link to non-standard C libs and it's not always obvious what packages they need. Of course, specifying external libs is not simple since different platforms often call them different things, but perhaps we could have some non-binding hint fields. Or perhaps we should just try and guess based on the names of the libs that need to be linked to (though that doesn't cover deps on other programs rather than C libs).

How about asking the distribution specific package manager program to which package the library file belongs? However, this requires that the dependent package is installed on the packaging machine.

Yes, for C libraries it's a pretty good hint. It doesn't help us with dependencies on programs or non-C libs however. Duncan