[dm-devel] multipathd.init
christophe varoqui
christophe.varoqui at free.fr
Sun Apr 3 09:43:37 UTC 2005
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 at free.fr>
More information about the dm-devel
mailing list