cvs commit: ports/archivers/hs-zip-archive Makefile distinfo pkg-descr pkg-plist ports/devel/hs-binary Makefile distinfo pkg-descr pkg-plist ports/devel/hs-darcs/files patch-Setup.lhs patch-darcs.cabal ports/devel/hs-darcs Makefile distinfo pkg-d

[Gabor PALI]

2010/5/27 Alexey Dokuchaev <danfe at freebsd.org>:
> It's that I just do not feel like fighting with python@
> cabal at this point, yet we can (right now) do something together so
> Haskell ports avoid similar kind of mess.

Yes, that is my goal too.  Together with a handful of guys (Giuseppe,
Ashish) we are trying to establish and then enforce policies on
Haskell ports.  That is why I am trying to keep our ports under
control of haskell@ (independently of their maintainers), and that is
why I am spamming Edwin when the GNATS AutoAssign tool routes PRs to
the wrong place (because it seems to prefer committers over group of
committers -- but still have not looked at its sources to find out
why).

I am also experimenting with a tool for automagically converting Cabal
hackages into FreeBSD ports [1] (built upon bsd.cabal.mk) which might
help to ensure these rules are not violated.  It is similar to
portlint(1) but it is proactive: it does not check for correctness,
but guarantees correctness.  I think Python ports may also use
something like that, but I do not know how trivial the conversion is
in that case.

You might say that "I could care less about the language that uses
noone", but please abstract away from that: here we are talking about
a global problem effecting on every similar category.


> Good question, this is tough choice.  It seems that the problem here is
> that while all of the above are technically mainly regular programs or
> utilities, some of them are hardly being interesting or useful outside
> of Haskell developer playground, others (like Xmonad) can be treated as
> completely self-contained and (most importantly) self-valued pieces of
> software.

I think I have found a solution (see below).  Comment on it, please.


> My point is more generic of that, though: use the right
> tools for the right things: e.g. do not abuse port name for encoding
> metainformation other than port's name.

In the strict sense, PORTNAME is still the port's name.  PREFIX is a
meta information which appears in DISTNAME, I do not think it has to
do with directory naming, but how to avoid clashes then?


> It's very unlikely that two ports fall in the same primary category
> (ergo, directory) with the same name.

Let me show nice counter examples (some of them are not ported but
they might be ported):

  audio/libmpd vs. audio/hs-libmpd [2]
  audio/jack vs. audio/hs-jack [3]
  devel/llvm vs. devel/hs-llvm [4]
  graphics/cairo vs. graphics/hs-cairo [5]
  graphics/graphviz vs. graphics/hs-graphviz [6]
  lang/pugs vs. lang/hs-Pugs [7]
  math/calc vs. math/hs-calc [8]
  math/gnuplot vs. math/hs-gnuplot [9]
  net/wol vs. net/h-wol [10]
  misc/toilet vs. misc/hs-toilet [11]
  security/py-twofish vs. security/hs-Twofish [12]


And they are also in the same primary categories. By analyzing them
will lead to my solution.  Only two of them is accidental (toilet and
jack), all the others are matching for a definite reason.  The reason
is: they want to provide Haskell bindings to the given application
(e.g. gnuplot, graphviz, llvm, etc.) or provide a Haskell-based
solution for the very same problem, therefore it has the same name
(e.g. calc, wol).  I do not see clear guarantee for avoiding name
problems without a prefix (which is a "qualifier" in that sense).

The conclusion is: the Haskell folks really deserve their own
namespace, eh? :)  They have over 2,000 packages already [13], and the
number of those packages keeps growing along with the probability of
an accidental name clash.

What to do with darcs and xmonad then?  Because both of them might be
used without Haskell (however, for xmonad, I am still in doubt),
"split" but not "share" them between the interested audiences.  Let us
take darcs as an example.

- Create a devel/darcs port which contains everything but Haskell
libraries and the Haskell API documentation.  If somebody wants to use
darcs as an end-user application and not a module, this must be fine.

- Keep the devel/hs-darcs port as a Haskell binding to devel/darcs
(itself) with a dependency on devel/darcs.  This way the user (or a
dependent port) has both the application and its modules.

For xmonad it is tricky, because you need to "develop with xmonad" in
order to configure it.  This approach is also used in xmonad-contrib.
For pandoc it is already supported, no hacks needed fortunately.  Port
xmobar is clearly an end-user application.


Cheers,
:g

[1] http://code.haskell.org/~pgj/projects/hsporter/
[2] http://hackage.haskell.org/package/libmpd
[3] http://hackage.haskell.org/package/jack
[4] http://hackage.haskell.org/package/llvm
[5] http://hackage.haskell.org/package/cairo
[6] http://hackage.haskell.org/package/graphviz
[7] http://hackage.haskell.org/package/Pugs
[8] http://hackage.haskell.org/package/calc
[9] http://hackage.haskell.org/package/gnuplot
[10] http://hackage.haskell.org/package/wol
[11] http://hackage.haskell.org/package/toilet
[12] http://hackage.haskell.org/package/Twofish
[13] http://www.haskell.org/