[Ocfs2-tools-devel] Re: ocfs2-tools for Debian/Ubuntu

[Joel Becker]

On Mon, Jun 27, 2005 at 11:26:07PM +0200, Fabio Massimo Di Nitto wrote:
> - - the 2 {ocfs2console,ocfs2-tools}.copyright files are identincal. You can just
>   rename one of them copyright and remove the other. The file will be installed

	Ok, cool.  Please forgive me when I don't know the ins-and-outs
of debhelper, it's been two years since I last did a debian/ from
scratch (and this one actually started as cp -a from another of my
programs).

> - - you can safely remove all the *.{pre,post}inst files. When only the #DEBHELPER#
>   keyword is required, the different dh_* tools will create them for you appropriately
>   and include in the package. No need to carry around N empty files.

	Ditto.

> - - The README.Debian is empty :). There is no real need to ship one. It's up to maintainer
>   if you want to ship extra specific distro documentation or information to the user, but
>   it's not mandatory.

	Somehow I thought it was.  Might be putting some info in there
though (see below).

> - - debian/rules is pretty ok. I usually (but this is really a personal preference) remove
>   all the calls that are not needed to build the package. Including the ones that are commented
>   out from the different examples.

	I leave them in because I have this debian/rules from a package
with both binary-dep and binary-indep packages, and seeing the commented
out lines helps me remember what debhelper stuff I can use (silly, I
know, but again I'm not a debhelper expert.  In fact, I just moved to
dh_install from dh_movefiles in these packages last week).

> - - we share basically the same debian/control (compared to ubuntu). You can safely bump
>   Standards-Version: from 3.5.6 to 3.6.1. The package seems clean enough for that,

	Ok, Ill do that.

> You builded very nice packages for sarge, but I think we should also look at what would
> be the future of it. In Ubuntu i used python2.4 and given that it is also in Debian,
> it is worth to leave 2.3 behind.

	Yosh will have to comment on this.  We both run sid, and I'm
wondering how the python-gtk2 stuff fleshes out with python2.4.

> Another little thing that i noticed is that you make use of /etc/default/$pkgsname. Since
> ocfs2 requires also the cluster config file, I did put them together in /etc/ocfs2/

	We package for Debian, Red Hat, and Novell.  Those all do this
sort of thing in /etc/sysconfig.  In Debian, the equivalent is
/etc/default.
	We kind of thing of /etc/default/o2cb as "the configuration for
the /etc/init.d/o2cb script", where as /etc/ocfs2 is "the configuration
for the cluster".  They are quite distinct, but if Debian folks were
really insistent on keeping them both in /etc/ocfs2, I don't know that
I'd fight really hard.

> The last thing (that i still need to fix in Ubuntu too) is the way in which the configfile
> (/etc/default/o2cb) is manipulated. Using "/etc/init.d/o2cb configure" is not exactly the
> Debian way of doing packages configuration.

	No, but it is consistent with how the software works across the
multiple distributions.  There is no debconf on Red Hat or Novell.
	This touches on a couple of personal biases as well.  I
personally feel that package installation and package configuration are
two seperate steps.  It frustrates me to no end when debconf pauses an
installation/upgrade I left to run unattended.  On AIX, I used to do
distributed upgrades on 100 machines at once.  Because installation
never paused to ask a question, I didn't even need stdin attached.
	It also runs into the fact that I never found debconf docs easy
enough (or visible enough, even) to get my feet wet.  If you want to
provide debconfification, cool.  I suspect a reasonable compromise would
be to debconfify the stuff, but still allow "/etc/init.d/o2cb configure"
to work.  Most folks just wouldn't ever need to run it, because it was
debconf'd at install time.

Joel

-- 

"Where are my angels?
 Where's my golden one?
 And where is my hope
 Now that my heroes are gone?"

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127