[xmonad] Small announce about the completion of the bluetile merge

[Gwern Branwen]

On Mon, Dec 7, 2009 at 7:43 PM, Joachim Breitner <nomeata at debian.org> wrote:

> Well, dynamic linking is just about to enter ghc, and it has no ABI
> guarantees: Expect the distro maintainers to have to re-build the xmonad
> package everytime one of the libs changes for years or indefinitely. :-)

:( Oh well, it wasn't a *crucial* argument anyway...

> I think this proposal is orthogonal to whether we want to have a
> bluetile binary: xmonad, even in an extended, user-friendly version is
> still different from bluetile. I think both have their merits and can
> co-exist. (You know, it’s like Debian and Ubuntu, different name, more
> shiny, same thing basically :-))
> Also, the gtk2hs-dependency and thus cabal-uninstallability of bluetile
> forces this fact.

Agreed. It's been a while since I looked through bluetile and I'm not
sure what the current status of all its pieces are, but there's a lot
that we can all probably agree to put into the standardConfig without
including any bluetile stuff: the first-run xmessage prompt,
SmartBorders conditional on no-Xinerama, checking the installed
binaries to see whether to recompile ~/.xmonad/*, a --restart flag (or
run by default) if it doesn't make it into -core, etc. I don't have a
complete list, but I'm sure there are lots of bits of code and modules
which have been suggested for -core and rejected because they were
minimalistic even though they were fine on their own merits.

> Actually, it’s in the transitive closure of the Recommends and will thus
> be installed by default :-). The README.Debian also lists the packages,
> and I hope that users look for an overview about xmonad not only in the
> package descriptions. Concrete suggestions to improve these are welcome,
> of course.

My bad then. I was only looking at the webpage; I suppose if Synaptic
or apt-get will install -contrib it's maybe not an issue for
Debian-like distros. (Although that's only part of the Unix world.)

> I’d not use a one-file-cabal file for the xmonad binary, but just copy
> that file to the debian package, but that’s an implementation detail on
> my side and not visible (besides by the fact that the Debian xmonad
> package will have the version number of the -contrib package it was
> built with, which probably makes sense anyways).

That's interesting. I was thinking about how to simplify the
distribution process; if there's no cabal file, how will people know
what this random .hs is or what it needs to be built and what name it
should be built under? With a one-file-cabal I reasoned distro people
would just have to run their magic cabal2deb tool a third time after
xmonad-core and xmonad-contrib and everything would Just Work.

-- 
gwern