cdbs vs dh vs ...

[Lucas Nussbaum <lucas@debian.org>]

On 21/03/19 at 08:38 +0100, Andreas Tille wrote:
> > So, to answer your question, I do think having a wide discussion and
> > then some final decision for it scheduled would be useful. I wouldn't
> > want to force dh9+ per sé (people still use CDBS and are apparently
> > happy with it), but I do agree those old style makefiles are holding us
> > back.
> 
> I do not want to turn this into a cdbs to dh flamewar.  Before dh 7
> Debian Med policy mentioned cdbs explicitly.  We moved away to dh now.
> I'm pretty sure the rsync maintainer would have refused a patch to
> convert to cdbs as well.  Several teams inside Debian have agreed to
> team policies recommending modern tools to simplify the life of all team
> members.  I'd love to see something like this for the Debian Developer
> team as a whole.

I think that we lack data about such evolutions (see
https://www.lucas-nussbaum.net/blog/?p=945 about solving that)

According to lintian data, the current status is:

udd=> select information, count(*) from lintian where tag='debian-build-system' group by information order by 2 desc;
             information              | count 
--------------------------------------+-------
 dh                                   | 24400
 cdbs-with-debhelper.mk               |  2010
 debhelper                            |  1942
 dhmk                                 |   227
 cdbs-with-debhelper.mk, debhelper    |   155
 other                                |   116
 debhelper, dhmk                      |     9
 cdbs-without-debhelper.mk            |     8
 cdbs-without-debhelper.mk, debhelper |     4
(9 rows)

(see also https://anarc.at/blog/2019-02-05-debian-build-systems/ )

I uploaded a list with maintainers and packages at
https://blop.info/pub/helpers.txt
(generated with

select information, maintainer, count(*), array_agg(source)
from sources inner join lintian on sources.source = lintian.package
where tag='debian-build-system'
and information != 'dh'
and release = 'sid'
group by information, maintainer
order by 3 desc;
)

Looking at the list, it seems that outside of some teams that
standardize on tools that do not use dh directly (Haskell, Qt/KDE), and
teams that have not yet migrated everything to a new tool (Perl, Java,
OCaml), there's mainly a long tail of packages that are probably quite
outdated.

The difficult question (not really for the DPL candidates, but they can
answer it ;) ) is: how do we decide that dh is the recommended practice,
and that non-recommended practices get a lintian warning?

Lucas