[Debian-ha-maintainers] DLM packaging

[Ferenc Wagner]

Christoph Berg <myon at debian.org> writes:

> Re: Ferenc Wagner 2015-08-29 <87oahpzrze.fsf at lant.ki.iif.hu>
>
>> I'm packaging DLM 4.0.2. Previously, this was part of the redhat-cluster
>> source package, but now it's a separate project at
>> https://git.fedorahosted.org/git/dlm.git.  Shall I file an ITP for this?
>> Or shall I copy the redhat-cluster changelog and continue that?
>
> IMHO ITPs are really only useful if you 1) want to make sure no one else
> would duplicate the packaging work you are planning (probably unlikely
> here, and your mail here is already some sort of ITP), or 2) you want
> some extra publicity on debian-devel ;).

Or 3) I want to stop Lintian complaining loudly about a missing ITP
number in the first changelog entry.

> The changelog question is orthogonal to that - if you are borrowing
> code from the old debian/, I guess you should copy it, otherwise start
> from scratch.

I didn't take anything from the old debian/, but the upstream code is
mostly the same (I guess), and the binary package names are the same, so
a continuous changelog still seems reasonable to me.  And it also shuts
up Lintian. :)

>> In the future this new dlm source package will produce some of the
>> binaries previously produced by redhat-cluster.  What coordination does
>> this require?
>
> If the new binaries are drop-in replacements for the old binaries
> (most notably, have the same name), the only coordination needed is to
> stop building them from redhat-cluster.

I think redhat-cluster should be dropped entirely, never to be uploaded
into unstable again.  (Just like the openais package.)  DLM and
gfs2-tools were split out of it and carried forward, while the rest
(cman etc.) has been deprecated for years.

The new DLM builds against the new Corosync, and LVM builds against
those two.  I'll soon be testing the resulting clvm and cmirrord.
-- 
Thanks,
Feri.