[DRBD-user] Debianization (was: DRBD 0.7.4)
dkrovich at csee.wvu.edu
Sat Sep 18 04:26:26 CEST 2004
<helmut.wollmersdorfer at gmx.at> writes:
> The problem is, that there is demand from users to have the latest
> development versions available with debian-packaging.
I'll take the hit on that one. I certainly haven't been doing a good
job of getting the latest drbd packaged into Debian. I was under the
impression that 0.6.x was for Sarge, and that 0.7.x or beyond would be
for sarge + 1 (aka etch). However, at the very least, 0.7.x packages
should be sitting in experimental.
> Having the debian directory in the upstream version is a little
> inconvenience for the developers, and a very less inconvenience for
> the maintainer (I assume), but it is a large convenience for many
> Personnally I am not a great friend of differences between developer
> and distribution versions, if there is no _serious_ reason.
Things could be worked out with upstream to make coordination of the
debian directory easier. Here are some steps that could be taken.
1) Don't put code changes in the debian/changelog. The debian
changelog should only be for changes to the debian packaging, or
closing bugs that have been filed in the Debian BTS. For code
updates, the ChangeLog file at the base directory of the source tarball is
the appropriate place for that information. It does not need to be
duplicated in the debian package changelog.
2) Don't tag a package as being for unstable unless it is actually
destined for unstable. Also, lets come up with an alternate
versioning scheme that will interact well with Debian versioning.
For example, in the current drbd-0.7.4 tarball, in the changelog
drbd (0.7.4-1) unstable; urgency=low
Instead, I propose:
drbd (0.7.4-0) experimental; urgency=low
Now, lets say drbd-0.7.4-1 makes it into debian, but due to lag or
whatever there is a desire to make changes to the debian directory.
For that case I would recommend:
drbd (0.7.4-1upstream1) experimental; urgency=low
If another upstream version came out before it was packaged in debian,
you could do:
drbd (0.7.4-1upstream2) experimental; urgency=low
Now, lets say a new version of the package goes into Debian. It would
drbd (0.7.4-2) unstable; urgency=low
And then upstream could increment that via:
drbd (0.7.4-2upstream1) experimental; urgency=low
Hopefully this makes sense. I'm definately open to other suggestions
on how to make this process better.
> At least I see the necessity to have a co-maintainer for DRBD to avoid
> too large time lags.
I agree, and fortunately Phillip Hug is stepping up to help out.
>> I would assume some people are still more comfortable using 0.6.x
>> over 0.7.x, so we would want to keep both versions available.
> Maybe some users of Kernel 2.2.x or Woody want to have 0.6.x still
> available. But 0.7.x is more important and the release of 0.8.x is
> maybe coming within months (and not years).
For me personally, I'm sticking with 0.6.x using a 2.4.x kernel on my
production systems until I get time to adequately evaluate and test
0.7.x. Having no 0.6.x version available in Debian would suck for
Obviously, there is a way to have both packages exist at the same time
in Debian. However, I think getting a 0.7.x version of drbd into
sarge would be somewhat difficult. Phillip, can you shed some light
on if getting a 0.7.x drbd package into sarge would even be possible?
More information about the drbd-user