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
signature.asc
Description: This is a digitally signed message part.
-- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk