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

[Joachim Breitner]

Hi,

Am Donnerstag, den 10.12.2009, 00:07 +0100 schrieb Jan Vornberger:
> For the most part yes - but Bluetile has it's own Main.hs and it is a
> little bit more elaborated then just doing 'main = xmonad
> bluetileConfig'. For example, it also checks if gnome-terminal is
> available and falls back to xterm if that is not the case.

This is not necessary on Debian, where you just use x-terminal-emulator
by default. (Doesn’t hurt either, don’t worry)

> It also starts the helper applications and displays some start-up information.

Any chance to have this bit of code in the module that exports
bluetimeConfig, e.g. as bluetileStartup.

> So I think it would be better to build the bluetile package from the
> bluetile hackage package.
> (About the terminal thing: That might be an opportunity to use Debian's
> x-terminal-emulator or some such thing. Let me know if I can make such
> 'debanization' easier in any way.)

It’s easy for me to patch these defaults, as I’m doing already:
http://patch-tracker.debian.org/patch/nondebian/view/xmonad/0.9-1


> If I may ask: You seem to be doing a lot of cutting and slicing. :-) I
> trust you know what you are doing, as you have experience with packaging
> for Debian, but does this really make things easier? A release of
> xmonad will always require a release of bluetile, so why not just keep
> the helper applications in that same package and just recompile them in
> the same go. It doesn't hurt, does it?

Make sure you keep in mind that Debian has a distinction between binary
and source packages. A release of the xmonad source will require the
debian source package to be re-built, producing a bunch of binaries. If
the bluetile binary is built from that, I’m done, and do not wast
resources re-building the (probably unchanged) bluetile-utils binaries.
If the bluetile binary builds from the bluetile source package, I need
to rebuild that source as well, producing new bluetile-utils packages
even though that can be avoided.

> Actually, the helper applications did live in an extra repository called
> bluetile-utils at some point. So I guess we are thinking alike. :-) But
> then I decided to just merge them into one repository to have less
> things to manage.
> It also opens the possibility to integrate the dock closer with the rest
> of the code. Right now it's self-contained, but at some point I might
> make it aware of things like how many workspaces are configured in
> bluetileConfig to adjust accordingly. That would break the bluetile vs.
> bluetile-utils separation, I suppose, and I don't want to create extra
> work for you.

If that happens I can just undo the split :-)

> So yeah, just curious what your motivation behind it is? But do as you
> see fit and let me know how I can help! :-)

I’m happy to explain my plans, but don’t worry too much – I can cope
with your plans and will complain loudly if that’s not the case any
more.

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/20091210/d7ae896a/attachment.bin