Deprecated debian packaging format

[hsbasu]

Several packages: mint-themes, mint-y-icons, mint-x-icons and several others use deprecated debian packaging formats and very old standard version. I would like create PRs for these packages. Would that be necessary?

[clefebvre]

Hi @hsbasu,

I'm not against it but I'm always wary of regressions, especially when the changes don't bring anything tangible for users. For example we recently faced significant unforeseen regressions when switching to debhelper 10.

I'd suggest to go step by step, project by project rather than doing it all in one go for all projects. I'm not sure how to scan for potential regressions.. I'd compare the old vs new packages personally, to make sure no filenames/paths/permissions changed.

[hsbasu]

Hi @clefebvre , I totally respect your decision. We should always deliver the best and latest to our users. But the regressions that you talked about, can you give an example?

[clefebvre]

Well for instance, migrating mintupdate from debhelper 9 to debhelper 10 resulted in its systemd services being automatically enabled. This made anyone who took the update get automated updated enabled.. not only that, but we couldn't release an update to revert this, since we had no way of distinguishing between people who suffered from it and people who enabled them manually.

More info at https://blog.linuxmint.com/?p=4336.

Debian delegates quite a lot to debhelper and changes things like that now and then. Most of the time these changes are OK, but they always need to be reviewed.

[hsbasu]

In that case, I think I'll do these one by one. After one has been tested extensively and merged, then I'll update another one. Is that okay? For starters I'll do the theme packages and application packages like xed etc. which doesn't affect the core system.

[clefebvre]

Yes, that sounds good. Compare the old and new pkgs to make sure paths and files are identical, that usually finds most of the issues.

[Fantu]

yes, packaging changes need check good, dump debian compat require to check various thing, is not only a version bump: https://manpages.debian.org/testing/debhelper/debhelper-compat-upgrade-checklist.7.en.html
there are also cases where packaging don't keep updated and checked had regression also keeping same compat version (even if less probable) or change in build system and in the software itself without considering the packaging that can cause issue.
I don't checked mintupdate packaging but for service like this I think is better have also a configuration file for set if and what do instead simply do on service enabled
About management of service enabled I already did on packages I maintain and is possible set the default for package configuration and consider also the choice of users to updates if I remember correctly
on d/rules override of dh_installsystemd there are --no-enable and --no-start, is also possible do multiple for multiple services specifying which ones to enable/start by default and which ones not
https://manpages.debian.org/testing/debhelper/dh_installsystemd.1.en.html