On Fri, Jun 25, 2010 at 11:07:30AM +0200, Jeremy Lain?
wrote:> Just a heads up to let you know I uploaded ocfs2-tools 1.4.4 to Debian
yesterday. It will take a couple of days to make its way into Debian/unstable
because I introduced two new packages following a user's request:
>
> - ocfs2-tools-pacemaker : package containing ocfs2_controld.pcmk
> - ocfs2-tools-cman : package containing ocfs2_controld.cman
Thank you! You are absolutely correct to separate out the
controld packages. We intended them to work that way. I hope that
you've kept the base ocfs2-tools package from requiring the complicated
dependencies of cman and pacemaker.
> => some time ago I suggested the "debian" directory be dropped
from the ocfs2-tools source tree, as it is very much out of date. Proskurin
Kirill's recent email on this mailing list seems to confirm this is
confusing to users.
You're probably right about this. Would you be ok with a
vestigial debian/rules that specifies the URL to get the current debian/
directory?
> B/ ocfs2-tools's source code does not compile with GCC 4.5, we had to
apply the following patch:
>
>
http://svn.debian.org/wsvn/collab-maint/deb-maint/ocfs2-tools/trunk/debian/patches/gcc45-ftbfs.patch
Well, that's less fun, but I suppose I can see the problem.
> C/ the manpages for mkfs.ocfs2 and o2image contain lines which are too
long. I apply the following patch to address this:
>
>
http://svn.debian.org/wsvn/collab-maint/deb-maint/ocfs2-tools/trunk/debian/patches/shorten-manpage-lines.patch
Gonna NAK this one, because the root at node is inconsistent with
the rest of the examples. Better to keep the hostname and wrap the
line.
> D/ Debian has switched to a dependency-based init system, so the LSB tags
in the init scripts are of vital importance now. While packaging ocfs2-tools
1.4.4 I encountered some issues:
>
> - the ocfs2 init script does not list $local_fs in it's Required-Start
and Required-Stop. I think this is wrong because the init script makes use of
"/var", which requires the local FS to be mounted.
The hard part about the LSB tags is that many distros break when
you fill certain things in. That said, I can't see why $local_fs would
be a problem.
> - the ocfs2 and o2cb init scripts state that they should be started in
runlevels 2, 3, 5 and don't specify when they should be stopped at all. In
Debian, we have always started these two scripts in the "S" runlevel,
and stopped them in the 0 and 6 runlevels (halt and reboot), so I have adjusted
the LSB tags to reflect this. What is your opinion on this?
The problem is that other distros do not have the network and
block devices up until the middle of the regular runlevels. EL5, for
example, starts the network at S10 in runlevel 3, and iscsi at S13. At
least they start mdadm in rc.sysinit ;-)
I don't have any problems with Debian choosing runlevel S, but
our scripts need to work on most systems. While the $local_fs change
probably wants to come upstream, I think the runlevel S patch should
remain in your vendor patches.
> E/ I have recently closed a crash report against ocfs2-tools in
Debian's bug tracking system because it is triggered by an erroneous use of
the cluster.conf config file, but it might still be worth investigating. If two
clusters are defined in the cluster.conf file, a crash will occur due to a
double free:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424922
We definitely support more than one configuration in
cluster.conf, even though we only support one _active_ configuration at
a time. I think this bug has been fixed, either in the master branch or
in a queued patch.
Joel
--
Viro's Razor:
Any race condition, no matter how unlikely, will occur just
often enough to bite you.
Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127