On martedì 2 gennaio 2018 11:47:04 CET Maximiliano Curia wrote:
> ¬°Hola Pino!
> 
> El 2017-12-29 a las 12:41 +0100, Pino Toscano escribió:
> > I would like to know why you are switching all the packages away from 
> > dhmk to "pure debhelper".  Sadly, the commit messages do not explain it 
> > at all (and they are even hidden from changelog, "Gbp-Dch: Ignore"), 
> > and I do not see any discussion here about this.
> 
> Because dhmk hasn't been maintained in quite a while (it supports things up 
> to 
> compat 7, afaicr),

It is used with compat 9, and recently some packages were bumped to
compat 10, apparently with no issues.  If you notice any issue, please
do report.

> it doesn't support bin and indep targets,

It is supposed to (Modestas wrote it when these targets were introduced
in Debian).  If it does not, then please do tell that, so it can be
investigated, instead of silently discarding it.

> it raises the  entry bar for contributions,

How?

> and it's a build system that nobody else is using.

Weak argument.

> About the debian/changelog I considered this change only relevant to us, and 
> not to the users.

debian/changelog is about *any* change done between the previous
version and the new version.  By your logic, things like
- "bump the group breaks"
- "update the build deps from cmake"
- "bump Standards-Version"
- "add patch to fix build"
should be hidden too, since they do not matter to the users...

Please document everything, really.

> > So far, switching only causes regressions, like overlinking (since dhmk 
> > takes care of adding as-needed).
> 
> Thanks for checking this, I guess we can add a compulsory:
> 
> export DEB_LDFLAGS_MAINT_APPEND := -Wl,--as-needed

It is not just that -- there are also more things done with dhmk:

* disabling --no-undefined -- OK, not used nowadays, but it was briefly
needed for few packages in the past (IIRC)

* library-packages.mk & libpkgs_gen_strict_local_shlibs, which hooks
into dhmk

* l10n-packages.mk & l10npkgs_firstversion_ok, which hooks into dhmk

* $(overridden_command), which takes care of invoking the command of
the override with all the needed parameters; while this seems trivial
to replace, imagine all the times -S/--buildsystem=kde/kf5 was
forgotten when overriding dh_auto_configure... which makes all the
Frameworks 5.41.0 in experimental :-) (thanks for proving my point)

* it automatically uses the right addons (kf5 and pkgkde_symbolshelper)
with no need to repeat them -- I recently thought about using sodeps 
by default (and simplify dependencies in control for -dev packages a
bit)

Sure, all the things above are doable even without dhmk... but by
bloating each rules file with lots of things repeated over and over,
and considering the number of kde-related packages, a copy&paste job
for more than 150/200 sources is not exactly what I'm looking for.
When working now on Applications 17.08.3, I saw way too many wrothings
wrongly copy&pasted from one source to another, so indeed the problem
is not just theoretical.

So please, do not drop dhmk right now.

-- 
Pino Toscano

Attachment: signature.asc
Description: This is a digitally signed message part.

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Reply via email to