Hi Christopher, On Thu, 21 Sep 2023 16:19:25 +0200 Christopher Odenbach <odenb...@uni-paderborn.de> wrote:
> > Hi, > > I just stumbled across the same problem: Creating a package which > creates a system user and then gives this user ownership of a > directory. > Currently this is not possible as the user is created in > the postinst script at the very last point. Well, you can write your code after the #DEBHELPER# token.. but I guess this doesn't work for your use case? Do you have the same problem as Lars - " move the `#DEBHELPER#` marker to the top of the postinst script. But this would lead to related services being restarted (via the other debhelper snippets) before the directory permissions are configured. " or there is another use case where the current order does not work? If you have another example I'm interested in hearing it. > > The logical approach would be: > > - create the system user (preinst) > - install all files and directories ("inst") > - transfer ownership (postinst) > > In your last email you said you wanted to discuss this matter on > Debian Devel. So could you please be so kind? Yeah that was the idea, but then I realized that writing in preinstall doesn't work with this package design: the preinstall snippet will call sysuser-helper which is not guaranteed to be installed yet :( So far I can think of the following: 1. The code can be written entirely in the preinstall but this defeats the idea of having the code in a separate binary (sysuser-helper) which has drawbacks like this bug but also has other advantages that I would like not to give up; maybe there can be a specific option to do this? 2. dh-sysuser can grow an interface similar to systemd-tempfiles but less complex and specialized in changing mode and ownership to files and dirs and makes sure that the snippet in postinstall is run after the creation of the user (I'm not particularly eager to do this..) 3. declare that for such cases systemd-tmpfiles is mandatory (but I still need to check that the order is correct) In case 1. is not feasible, do you dislike 2? Would it work for your use case? > I really like the idea > of your package, but currently it does not really help me. I neglected a bit this package during the last cycle, hopefully I'll manage to do better in this cycle Regards, Lorenzo > > Thank you, > > Christopher >