[Pkg-roundcube-maintainers] Cleanup roundcube

[Guilhem Moulin]

Hi Sandro!

On Wed, 27 Jan 2021 at 03:42:48 +0100, Sandro Knauß wrote:
> after some month I found time again to look at the roundcube package and I 
> have no glue at all what have changed.

Does d/changelog, `git log` and/or `git blame` shed some light on this? :-)
 
> * I not found time to removed the patch that failed for others: retry-to-
> reach-imap-server.patch it would be nice if we get this into next stable. 

That's great!  I wanted to ask you what to do with that patch in
preparation for the Bullseye freeze, but you beat me to it :-)

> Should I do a release or are there any planed changes from your side in the 
> pipeline?

I plan to do one more before the freeze to clarify the status with PHP8.
(Was hoping to unbundle publickey-XXX.js and some more fonts as well, but
that might be tight now.)
 
> I created now a plugin for this in upstream to have the same functionality 
> without the negative effects: 
> https://github.com/roundcube/roundcubemail/pull/7844

Awesome, thanks!
 
> * copy of install-jsdeps.sh inside debian folder. As I marked in the header 
> once, it can be replaced with the version shipped from roundcube > 1.3.0. But 
> I think it is not used anymore anyways. So we can remove it?

Hmm, I vaguely recall trying to get rid of it when working on packaging
1.4 RC, and that it had to be preserved for the download phase (while
d/rules doesn't mention it, debian/missing-sources/README still does).
Tried again now and it works like a charm with `bin/install-jsdeps.sh`
(with patches applied of course).  Not sure what if I had the wrong
assessment in 2019, or if something changed meanwhile.  Anyway fixed in
8306e105f, thanks!

> * the d/rules looks quite complicated

Most of this complexity was introduced my me some weeks ago in eb4d202fe :-)
I didn't like the previous one

    https://sources.debian.org/src/roundcube/1.3.16+dfsg.1-1%7Edeb10u1/debian/rules/

with install rules mixed with build rules as Jonas Smedegaard rightfully
pointed out in #978075.  Moreover using for loops and/or `find | xargs`
prevent parallel execution and it's cumbersome to get error checking
right.

> aren't there things that should better been part of debhelper (some
> buildsystem etc.) I normally do KDE packages these days and there the
> rules file just have two or three lines ;) But it is not obvious what
> different parts can be bundled, so other packages also can profit from
> this work.
>
> * a lot of d/rules section can be moved to execute_after_dh_XXX (when it is 
> fine to use debhelper 13 also in backports)

I'm not sure which example you had in mind here, but if upstream had a
proper Makefile our d/rules would also become much simpler too :-)
AFAICT the complex stuff is the build system, so what runs *before*
dh_auto_build.  Maybe that part should best be shipped in the form of an
upstream Makefile, even though it might require tweaking as we for
instance generate configuration stubs in plugins/*/config.inc.php.dist.
I don't mind splitting d/rules into d/Makefile.roundcube and d/rules,
but I'm quite keen to keep a build system that makes use of the Makefile
dependency graph as it gives error checking and parallelism for free:
that was the essence of the recent eb4d202fe.  I'd also argue that
compared to d/*.install, using Makefile directives at dh_install* gives
more flexibility when a new plugin or skin is added; this even avoids
bugs reports such as #958642.
 
> Many many thanks for all your work you do for the roundcube package!

You're welcome :-)

Cheers,
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-roundcube-maintainers/attachments/20210127/bf6d6c34/attachment.sig>