Control: retitle -1 upgrades overwrites local style customization Control: severity -1 wishlist
On Thu, 09 Jul 2020 at 06:09:02 -0500, Bryan Walton (Debian) via Pkg-roundcube-maintainers wrote: > _styles.less, located in /usr/share/roundcube/skins/elastic/styles, is a > file that exists for local customizations of the roundcube templates. The > file, as shipped by Debian has one line in it, that reads: > > /* Here you can put your custom styles that will be appended to the output > css file */ That file (as well as ‘_variables.less’) comes from upstream. Not sure how best to add support for local style customization in the package. * We could build styles.css at postinst stage. This is my least favorite option, because it adds a runtime dependency on node-less, which transitively pulls in 61 new packages (>50MiB additional disk space) at install time on a minimal sid chroot with `--no-install-recommends`. It might also make the package uninstallable if lessc(1) upstream changes their CLI interface. This is not speculation, following a node upgrade less recently failed to write output to stdout. As of the current node-less/3.11.2+dfsg-2, `lessc -x` yields “The compress option has been deprecated. We recommend you use a dedicated css minifier, for instance see less-plugin-clean-css.” I would much rather have FTBS bugs than a broken postinstall script on (some) user systems. We could also ship styles.css, demote the dependency to Suggests: (which makes more sense than a hard Depends: given local style customization are purely optional), and only rebuild it when lessc(1) is found in $PATH *and* local changes are detected, keeping the file intact in case the command fails. However this is not satisfactory either as it'd make tools like debsums(1) might complain that the file doesn't match what's found in the package metadata. Plus the postinst script runs with root privileges and it seems non-ideal at best to run lessc(1) with these privileges. * We could add a note to ‘styles/_*.less’ saying the user needs to manually install node-less and manually run `less -x` after each upgrade. Not ideal either, we might preserve local changes to ‘styles/_*.less’ but will overwrite the CSS anyway. That shifts the burden from package maintainer onto users. Any other option? Avoiding overwriting users changes is the easy part. We could either stop shipping ‘styles/_*.less’, or better symlink these files from ‘/etc/roundcube/skins/elastic’ and let dpkg do the magic. Note that it is pretty usual to overwrite local changes outside of /etc (that is, unless the local admin adds a dpkg diversion); despite what the upstream file reads we never claimed otherwise, so I'm lowering the severity. -- Guilhem.
signature.asc
Description: PGP signature