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

[Joachim Breitner]

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 at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://www.haskell.org/pipermail/xmonad/attachments/20091207/3f036a68/attachment.bin