
Hi, Am Montag, den 07.12.2009, 19:27 -0500 schrieb Gwern Branwen:
- Distro & package maintainers bear very small costs since the package is really small and simple. Quite possibly it may not need updating for years or indefinitely once we get dynamic linking. (Since, if I understand the idea right, the compiled program would not hardwire the xmonad libraries but point to libxmonad.so or something, and would get new versions of 'xmonad' and 'standardConfig' everytime the respective libraries were changed.)
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. :-)
- This idea is better than some separate 'bluetile' executable package. dons and others have spent years publicizing xmonad. People who want xmonad install 'xmonad'. The people who would benefit from it are almost by definition the people who would not know about it until too late.
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.
Nor can we add an executable section to XMonadContrib for exactly the same reason. Someone just trying out XMonad may well never install -contrib or even know about it until they begin complaining. If you knew little about Xmonad and saw the Debian description at http://packages.debian.org/sid/xmonad would you be able to instantly infer 100% of the time that "Xmonad is configured in Haskell, and custom layout algorithms may be implemented by the user in config files" implies that there is an enormous collection of extensions & customizations called xmonad-contrib? I mean, -contrib isn't even a recommended or suggests!
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.
- this requires effort and approval from many people. (How many distro maintainers do we have? 3 or 4? Toss in another 3 for the -core devs, and then maybe a few more for people in favor of the general idea of a default userfriendly config but really couldn't we just make it another XMC module or something. Hard to have a consensus or get anything done with 10 people complaining, and this doesn't work if the official xmonad package doesn't change. It can't be done as a fork, as I covered above.)
I don’t mind your proposal and from my side the effort is doable. I’d then build the xmonad binary not from the xmonad (your xmonad-core) source, but from the xmonad-contrib source. I could actually start to do that today, if you provide me with suitable config in contrib :-). 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). My opinion though is that xmonad users will almost always want to recompile their window manager anyways, and the others are covered by bluetile, so I don’t see an urgent need for action here – but as I said, I’m not opposing it either. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata