BIRD 2.0.8

[Jakub Ružička]

On 4/14/21 4:24 PM, Ondrej Zajicek wrote:
> On Wed, Apr 14, 2021 at 12:45:28PM +0200, Jakub Ružička wrote:
>> Oh, I see! I checked history and this versioned requirement was added as
>> part of "Bump the dephelper compatibilty level to 12" in Debian package
>> which is a change specific to latest debian release. It's quite likely
>> that this specific version isn't in fact required so I removed the (>=
>> 1.56~) part - it's always worth a try with default available system
>> init-system-helpers. I see overly strict requires like this often when
>> doing cross-distro packaging. Sometimes they are introduced to dodge
>> specific bug but older version might still work.
> Hi, some time ago i built Debian packages for older Debians (8, 9) and
> did some modifications (including decreasing debhelper compatibility
> level) in order to work with unmodified system (without upgrading
> init-system-helpers from Backports). It worked without problems (with
> init-system-helpers >= 1.22~ requirement), but needed some modifications
> to Debian control files.
I've also carried out these modifications, see my other thread "BIRD
2.0.8 packaging update", specifically the opened MR:

https://gitlab.nic.cz/labs/bird/-/merge_requests/25

These changes would be even more useful if scripts/make-dev-archive.sh
(or equivalent script in bird repo) was adjusted to generate same
archive from current git repo that is used for official tarballs - maybe
you know how that's done?
>
> So it seems to me that in order to build packages for multiple Debian
> versions the simplest way is to have multiple Debian control files.
That initially looks like the simplest way but it turns out to be quite
the contrary in the long run. If we maintained one branch for each
currently active Fedora, Debian, and Ubuntu release we would already be
at ~12 branches and that's not counting other distros and their releases.

Downstream packaging is already maintained that way and it introduces
noticeable burden so for upstream packaging it's easier to have shared
packaging sources if possible.

Knot DNS and Knot Resolver projects (as well as many others in the wild)
have been using shared packaging sources successfully for quite some
time and apkg is my effort to create universal standard and format for
upstream cross-distro packaging.

Using shared packaging files for multiple distros is certainly
challenging but I assure you it's *significantly* more manageable than
juggling tens of separate diverging packaging branches for each distro
release(!). That work is already done by downstream packagers and
duplicating it centrally in upstream brings no benefits, only huge
amount of overhead.

In addition to downstream packaging which is targeted and specialized
for individual distro releases, upstream packaging should IMHO be as
general as possible in order to work everywhere. It should allow
developers to easily build and test packages from source at any point of
development and on any system as well as easily provide users with fresh
packages when needed (i.e. when when downstream packages aren't
available yet).


Cheers,
Jakub