
On Mon, Dec 7, 2009 at 7:43 PM, Joachim Breitner
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