Feedback on Ubuntu-specific debian/rules for building sysvinit

Joost van Baal-Ilić joostvb-debian at
Fri May 12 05:50:34 BST 2023

Hi Olivier,

On Fri, May 12, 2023 at 12:06:26AM +0200, Olivier Gayot wrote:
> Dear Debian maintainers of sysvinit,
> A few years back, we decided for Ubuntu to disable the build of sysvinit
> binary packages except for sysvinit-utils which is marked [essential].
> To achieve this, we added in debian/rules a bunch of ifeq/ifneq statements
> in override_dh_* rules disabling some instructions if we are building on
> Ubuntu [1]. As an example, we want to disable the following instructions if
> we are not building sysvinit-core or bootlogd:
> dh_installchangelogs -psysvinit-core doc/Changelog
> dh_installchangelogs -pbootlogd
> We used to manage this Ubuntu delta internally and would rebase on top of
> Debian when new releases would come out.
> However, since the move of some scripts from lsb-base to sysvinit-utils,
> there is now some Ubuntu-specific code in Debian d/rules [2]:
> ```
> derives_from_ubuntu := $(shell (dpkg-vendor --derives-from Ubuntu && echo
> "yes") || echo "no")
> ```
> ```
> ifeq ($(derives_from_ubuntu),yes)
> ifneq (,$(findstring sysvinit-utils, $(shell dh_listpackages)))
> 	cp -p debian/src/lsb-base/init-functions.d/50-ubuntu-logging \
> 		debian/sysvinit-utils/lib/lsb/init-functions.d/
> endif
> endif
> ```
> It feels counterproductive for Debian and for Ubuntu that our
> Ubuntu-specific sysvinit configuration is partially managed in Debian and
> partially in Ubuntu. So I would like to get your honest opinion on what you
> think would be the best approach going forward:
> Option 1: Consolidating Ubuntu-specific configuration in Debian
> ---------------------------------------------------------------
> We would move our Ubuntu-specific configuration in Debian. The result would
> make it much easier for Ubuntu to keep up with Debian (no need to rebase ;
> we can go back to syncing). Sadly, it will also add a little bit of
> gratuitous code on Debian's d/rules but we can work on making itless
> intrusive though. I believe there are more than one way to achieve this:
>   * Add a few more ifeq/ifneq statements leaning on $(derives_from_ubuntu)
> which is already defined. This would basically reflect what we have
> currently in Ubuntu [1]
>   * Add a few more ifeq/ifneq statements disabling some instructions based
> on the output of $(findstring <package>, $(shell dh_listpackages). I haven't
> tested it yet but I think it can be a cleaner way to honor the DH_OPTIONS
> without being too specific to Ubuntu.
> Option 2: Continuing partial management in Ubuntu and Debian
> ------------------------------------------------------------
> we continue having the Ubuntu delta partially managed in Ubuntu and in
> Debian. In my opinion, this is the least viable approach.
> Option 3: Removing Ubuntu-specific code from sysvinit in Debian
> ----------------------------------------------------------------
> We would basically drop the Ubuntu-specific stuff from sysvinit in Debian.
> We would manage our delta entirely in Ubuntu.
> Your feedback would be very appreciated.
> Thank you for the good work you put in Debian!

I do not oversee the complete picture here, but let me add this:

"Bug #904302: any use of dpkg's vendor-specific patch series feature is a bug
for packages in the Debian archive and such feature will be forbidden in the
Debian archive after the release of Debian Buster."

See , .

Some people felt very strongly that a build's result should be predictable, and
should therefore be as independent as possible of the system the build is
executed on.  Doing hidden / tricky things makes software more non free.  I
believe that was the gist of the thinking there.  Anyway, a valid argument in
my opinion.

Consequence here would be to keep all machinery on Ubuntu's side.

HTH, Bye,


> [1]
> [2]

More information about the Debian-init-diversity mailing list