Removing kits, in Sid

I am not exactly sure why I write this... but there might be two main reasons - I wasted enormous amount of time (80% of this googling crap) and need to get at least some kind of visible outcome. And secondly - it might be of help to someone as of 'how not to get results'.

The idea was to see if I can get rid of *kits in my Debian Sid. And possibly of PAM too. This last one I left aside pretty fast - too many unavoidable deps.
What consolekit and policykit do and why they are also shitty and unneeded part in single-user desktop, that can everyone google themselves.

In my Debian Sid I got such deps for kits: they and their libraries, and Lightdm. That was all, and life seemed rosy.

1. I removed lightdm and replaced it with slim (has optional consolekit dependency) from Debian repo.
As a by-thought - Slims' login-screen looks, frankly, like shit... But slim is real light-weight and easy to configure: /etc/slim.conf and themes reside in /usr/share/slim/themes. Graphical part of themes are quite extensive - and not so trivial to change. If pointed to correct folder, slim lists all your sessions automatically.
But never mind that - of course the debian slim had been compiled with consolekit support.

2. Recompiling slim with -DUSE_CONSOLEKIT=no. My installation needed additionally libpam0g-dev for that.
After playing around with original source - I even got it 'made' (after endless tries and some conf and parameter changes) - I decided for making proper debian package.
So I played several evenings with pbuilder and cowbuilder (there are tons of material to read, some heavy packages to install and not very simple conf to conf). I managed to create quite an impressive mess - and finally went for simpler way and used dpkg-buildpackage.
In very concise way, whole thing was like that:
apt-get source slim   # downloads source packages to current folder and unpacks tars in correct way.
-DUSE_CONSOLEKIT=no  - change it in /slim-unpacked-source/debian/rules
change conf in /debian/patches/slim-conf.patch to reflect your situation (less to do afterwards)
dpkg-buildpackage -rfakeroot -uc -b  # in source folder
and there should be new slim.x.x.deb in sources root.

3. Removing vanilla slim and *kits.
Went to console, killed slim and X, then removed slim, policykit, consolekit and deps. Installed:
dpkg -i slim...new-one.deb
Rebooted.
X did not start and dbus did not start (despite I had the second one in .xinitrc).
Manual dbus-launch worked but then X claimed to have a segmentation fault. Bugger!
I reinstalled consolekit - and X started without any problems... Double bugger!
To cut it short, after trying several things - to (unsuccessfully) root out consolekits' leftovers, I threw a towel.
Shame-facedly, I reinstalled both kits. That's that - a defeat.

At the same time - there are cases of successful removals. So, it can be done. I suspect that without display manager (but I wanted to keep it), linux-with-no-kits is possible.

PC-BSD, take 2

I have been feeling restless and somehow unsatisfied lately, kinda missing some thrill in my Linux adventures. Also, some part of it is my disappointment that Debian chose the future of systemd. Means that there will not be next stable Debian install for me. All in all - I decided to start with some slightly radical projects, one of which is new visit to BSD-land.
See the previous one here.

I dowloaded PC-BSD DVD-USB-version of iso, dd-d it to usb-stick:
dd if=PCBSD10.0-RELEASE-x64-DVD-USB-latest.iso of=/dev/sdd bs=1M
and booted it without problems. With my new and better box it didn't take very long for language-menu to appear. Whole installation looks roughly identical to ver 9.2.
Only filesystem available is zfs.
The new installing option is 'grub-slice' for planting grub2 to bsd root. What a joy - at last an option to escape fucked-up MBR, and get grub-generated correct boot-code!
... Well, it wasn't. Joy, I mean.
What I got was grub 'exiterror', indicating something like 'I can't understand so many partitions or labels or whatever'. And installation ended with 'Failed'.
I found quite a lot of the same when googling about it. What I didn't find was the solution.

I mused a bit over it - mind, quite relaxedly this time - as my expectations of successful installation wasn't especially high anyway.
Conclusion:
1. I really do not need zfs for my desktop. It's an overkill.
2. There seems to be quite a lot of difficulties to get zfs pool mounted in Linux - as BSD version of system tends to be newer than Linux-provided zfs-fuse. Means, one has to do various tricks for that, or - to get some common r/w partition for those op-systems (and no, freebsd does not recognize ext4).
3. And - I am not going to repair my MBR because some silly shit wants to overwrite it. One thing I expect from op-system is that it installs as I want it to be installed. PC-BSD still doesn't do it for me.
Formatted this special primary partition I had kept for BSD to ext4, and I might try Gentoo there ...

Because my previous BSD-post had a little part about Ghostbsd, then - I took a look. As is seen there, ver 4 alpha is out (and is based on Freebsd 10). Consequently - no install-attempts just now. But I will try when 4 gets released.