Hackage rocks

[Duncan Coutts]

On Sat, 2007-08-04 at 14:44 +0100, ross at soi.city.ac.uk wrote:
> Quoting Duncan Coutts <duncan.coutts at worc.ox.ac.uk>:
> >       * 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