Re: [dm-devel] multipathd.init

[christophe varoqui <christophe varoqui free fr>]

On ven, 2005-04-01 at 23:25 +0200, christophe varoqui wrote:
> On ven, 2005-04-01 at 22:19 +0100, Alasdair G Kergon wrote:
> > On Fri, Apr 01, 2005 at 11:09:04PM +0200, christophe varoqui wrote:
> > > Do we really want to do complicated things to close that window ? I
> > > would guess not.
> >  
> > In other words, if the paths can't survive the window between initrd 
> > running and init scripts completing, the machine doesn't deserve to boot.
> > 
> > And if you want the daemon in single-user mode, you can start it by hand.
> > 
> > Fair point.
> > 
> > So is there ever a requirement to run the daemon while /var is read-only?
> >
> I personnality guess not, but Debian people already got annoyed by that.
> Don't how they handled it in the end.
> 
Alasdair,

Would it ease your packaging work if I put this init script as
multipathd/multipathd.init.redhat ?

I could also rename the current multipathd/multipathd.init to
multipathd/multipathd.init.debian and stop installing it in the
'install' make target.

Debian people, and other distro packagers, may express their views too.

I also would like to kick off the debate on libsysfs and libdevmapper
klibc versions packaging, as I removed these libs from the
multipath-tools package and thus broke the klibc building framework.

What needs to be done to have libdevmapper and libsysfs packages include
their respective klibc build version ? What about klibc shared objects
vs static ?

Regards,
-- 
christophe varoqui <christophe varoqui free fr>