[PATCH] remove usage of g_assert() in blockdev

[Peter]

On Fri, 17 Nov 2006 20:49:51 -0500, Doug Goldstein wrote:

snip.....
>> What don't you like about HAL? I'm sure I would prefer specific points
>> we can discuss than a general rant.
> 
> No one wants their initramfs' to grow. No one wants to move all those
> bits that high in the start up stack (except maybe Ubuntu & Fedora).
> 
> But you're going to find a lot of non-desktop distros will not be
> appreciative of this move since they would rather see these bits as
> optional rather then running a bunch of extra daemon's and seeing their
> top level /bin & /lib grow.
> 
> I know Debian won't be a fan of this and I can speak for Roy (Gentoo
> baselayout maintainer) and myself (fd.o apps maintainer) that we don't
> want to see this move up this high in the startup stack.
>

Well, I can say from a user POV that any changes to the baselayout or
startup hierarchy would be unappreciated. Slackware, for example does not
provide even Gnome, let alone dbus, hal, etc. There is no assurance that
slipping hal up before udev would have any undesired consequences, and if
there were, official support would not be forthcoming.

Right now, hal is the very last daemon loaded. Sometimes, I don't even
load them at startup but right before I need gnome applications to run
(they require at least gnome-settings-daemon, and it needs dbus. Anything
which uses nautilus will want hal, and in the unstable gnome, that means
that gnome-mount-0.5 wants >=hal 0.5.8.1 which already does not work per
my email sent earlier.

The main issue I would have is that hal is not even stable at 1.0 yet. And
as we saw was dbus, how can we be sure that a move upwards in the daemon
hierarchy would be continued down the road? Any change like this,
if not permanent, would never be adopted due to support issues.

Anyway, this leaves me with two questions:
1) IF I moved hal before udev during startup, would that fix the segfault
issue from my other email, Subject: hal 0571 works, hal >=0581 does not?

2) IF hal is daemonized that high up, how would one run the hald daemon=no
command if the daemon is already running? Would the output from this
command be useless since it will have been loaded after udev?

-- 
Peter