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@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata