[PATCH] remove usage of g_assert() in blockdev

[David Weinehall]

On tor, 2006-11-16 at 09:10 -0500, ext Doug Goldstein wrote:
> David Zeuthen wrote:
> > On Tue, 2006-11-14 at 15:43 -0600, Steev Klimaszewski wrote:
> >> Not to mention the dependency of HAL on PolicyKit, which requires pam... 
> >> or am I missing something here?
> > 
> > (PAM already lives in /lib, at least on Fedora if not everywhere else.)
> > 
> > PolicyKit is used as a D-Bus service and is only used once callers start
> > calling into HAL. 
> > 
> > At a future point, when D-Bus system bus activation lands, PolicyKit
> > will probably just be started only if there is a need for it, e.g. when
> > HAL or others call into it... And then the daemon can exit too e.g. when
> > it haven't provided service to anyone for e.g. 1 or 2 minutes.
> 
> It does not remove the fact that everyone will be required to have PAM
> and use PAM. Which is not something everyone wants. The whole point is
> about choice. What you're essentially proposing is Microsoft here. It's
> shiny Vista. Why not make HAL display a boot splash which totally
> obscures the console.

Get real.  You don't have to use HAL.  If you use it, you have to either
live with the fact that it'll depend on PAM, or patch it yourself not to
need PAM.  The difference from Microsoft is a.) you don't have to use
HAL, and b.) you have the source, you can fix it yourself.

I've seen the same kind of complaints about udev...

> > Either way, having / and /usr on separate file systems doesn't really
> > make sense in this millennium I think. As such, moving HAL out of /usr
> > does not make any sense to me. I think we simply just want to advise
> > distributors that / and /usr needs to be on the same file system. 
> 
> It makes plenty of sense to lots of people and it shows your utter lack
> of experience with any real world Linux & UNIX systems. This is one of
> the most dumbfounding statements you've made on this list and is causing
> lots of people to be worried about the direction of HAL development and
> hopes to drop it from their systems.

Here I agree though, / and /usr must definitely survive being on
different file systems.


Regards: David