Some executables are shipped as conffiles

[antlassagne]

On debian based systems, a few files are in /etc but are not conffiles

• /etc/nvidia-mig-manager/service.sh should really be in /usr/libexec/nvidia-mig-manager (doc)
• /etc/nvidia-mig-manager/utils.sh should really be in /usr/share/nvidia-mig-manager (doc)
• The autogenerated config.yaml (from nvidia-mig-parted generate-config -f "${CONFIG_FILE}.tmp" would more properly be in /run/nvidia-mig-manager (doc)

Having everything in /etc make systems extremely challenging to upgrade. conffiles will be treated differently than other files by apt, they may not be overriden on upgrades, nor deleted on removal/purge.

Environment (please provide the following information):

• mig-parted version: [e.g. v0.14.2]
• Host OS: Ubuntu26.04

[antlassagne]

Hey @rajathagasthya, any thought about such an enhancement?

[rajathagasthya]

Hi @antlassagne! Thanks for the report. The point about scripts living in /etc is well taken.

One clarification: only override.conf is registered as a dpkg conffile, so service.sh/utils.sh/hooks.sh are replaced on upgrade and removed on removal like normal files. What does linger is the generated config.yaml and the hooks.yaml symlink, which are untracked and only cleaned on dpkg purge.

We can consider moving those files outside /etc in a future release (I need to think a bit more about this). Just curious, did you hit a concrete upgrade or removal failure?

[antlassagne]

Thank you for your response. I did not encounter any specific problem.

I was simply submitting mig-parted to the Ubuntu Archive (see here), and the archive admins always want to have the highest quality as possible. Specifically RAOF was raising these concerns and they are perfectly relevant, as non-conffiles should not live in /etc.

Of course if you have any feedback about this too, that would be most welcome. In particular, if any additional integration testing can be run without GPUs, I can make these tests part of the package.

[rajathagasthya]

Understood, thanks. Let me discuss with the team on the best way to move forward. We want to make sure things don't break for existing users.

[antlassagne]

I edited my previous comment - it seems hooks.sh can be considered, at least partially, to be configuration, so it should stay in /etc.