[debhelper-devel] `dh --with autotools_dev` and `dh_update_autotools_config`

Niels Thykier niels at thykier.net
Wed Aug 2 06:08:00 UTC 2017


Henrique de Moraes Holschuh:
> On Tue, 01 Aug 2017, Niels Thykier wrote:
>> I have offered to manage the deprecation and eventual removal of the
>> autotools-dev related debhelper tools + sequence if we were to go down
>> that route.  However, as mentioned, I have not heard from Henrique, so I
>> do not know if that is the way we will go.
> 
> Can you send me the detailed plan?  I don't have anything against
> deprecating the autotools-dev debhelper tools and sequence, as long as
> we don't break anything that currently relies on them.
> 

Certainly.  My plan is basically:

 1) Have the autotools-dev dh_* tools + sequence call
    deprecated_functionality (from Dh_Lib) and set compat 11 as
    the compat level removing the functionality[1].

 2) Have debhelper document this in the upgrade notes for compat 11.

 3) Have lintian emit tags for usage of the debhelper functionality from
    autotools-dev.

 4) Wait until the compat level is retired from debhelper.  This is
    measured in at least 3 Debian releases for compat 11 (including
    "buster") plus a 1 year more[2].

 5) Remove the tools from autotools-dev


The first step will choose how long the tools are supported as
deprecated_functionality needs a compat level to determine when the
functionality will be obsolete.
  It will also nudge people into migrating away as they bump compat
levels in their packages to the first compat level beyond the cut-off point.

The lintian warning will give people a heads up, help us remove the
tools in new uploads and help us estimate how many packages / consumers
remain in Debian.


Thanks,
~Niels



[1]
API description for deprecated_functionality:
> deprecated_functionality($warn_msg[, $rm_compat[, $rm_msg]])
>         Emit $warn_msg as a deprecation warning, or error out if $rm_compat
>         is provided and equal to (or greater than) the active compat level.
>         The $rm_msg parameter can be used to provide a custom error message
>         in the latter case (if omitted, $warn_msg will be used in both cases).
>         The function will provide a separate diagnostic about which compat
>         level that will remove/removed the functionality if $rm_compat is
>         given.

Wording improvements welcome; I think you will be the first consumer of
this function outside debhelper itself :)

[2]
I expect to adopt a new support policy that keeps compat levels as
supported (non-deprecated) until a newer compat level is supported in
oldoldstable.  Plus removal should happen at the earliest in the Debian
release after the first one that has the compat level as deprecated.

Plus that assumes there are so few consumers of compat levels left when
they become deprecated that it is actually feasible to remove them at
the earliest point.  I very much doubt that is the case; it certainly is
not for compat 7 and probably won't be for compat 9 either.




More information about the debhelper-devel mailing list