On 4 February 2026 at 12:25, Simon McVittie wrote: | Package: r-base-core | Version: 4.5.2-1 | Severity: wishlist | User: [email protected] | Usertags: dh-usrlocal | | Prompted by recent changes in fontconfig's handling of | /usr/local/share/fonts, I noticed that r-base-core's postinst has | an open-coded script to create /usr/local/lib/R with Policy-compliant | permissions. | | Please consider using dh_usrlocal(1) for this: that way, any implementation | bugs can be fixed centrally in debhelper, and they will take effect in | all packages that use dh_usrlocal at the next rebuild. | | The procedure to do that is something like this: | | 1. create debian/r-base-core/usr/local/lib/R | (for example with `install -d` in d/rules, or probably using | debian/r-base-core.dirs would also work) | 2. make sure dh_usrlocal is run (normally dh will run it, but I see that | r-base is using individual dh_ tools so it would be necessary to | insert an explicit call to dh_usrlocal at an appropriate point in the | sequence) | 3. remove open-coded logic in maintainer scripts to create (and possibly | remove) this directory | 4. make sure the #DEBHELPER# placeholder appears in any maintainer scripts | that still exist | | With that done, dh_usrlocal should insert maintainer script snippets | generated from /usr/share/debhelper/autoscripts/ to create and remove | the directory when appropriate.
What we use there is somewhat involved because of the required group write bit (so that 'allowed' R users can add packages). I am looking at the dh_usrlocal(1) man page now and am learning about /etc/staff-group-for-usr-local so this _could_ work but I am not sure I really want to introduce variance here now: what we have _works_ and expectations are built upon in. So will ponder but possibly decline. Appreciate the heads-up though. Cheers, Dirk | Thanks, | smcv -- dirk.eddelbuettel.com | @eddelbuettel | [email protected]
