Comment 39 for bug 1768610
Revision history for this message
| Marco Trevisan (Treviño) (3v1n0) wrote | #39 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
I've playing with this a bit more to get the fix for the currently affected users who already upgraded to bionic and removed nux-tools, but I don't think there's a solution which works if we keep this marked as a Conffile by dpkg.
In fact, using the various rm_conffile or just removing the file from a maintainer script in any other package, then if the user will try to reinstall unity (and then nux-tools), this config file won't be reinstalled, as it's still there according to dpkg.
If anyone know a solution in how we can manipulate the dpkg status from a maintainer script, that's the way, otherwise I've no other idea than going back to the solution I proposed in the last night's MPs of removing this conffile from nux-tools itself, storing it in /usr and then symlinking it (with new name) to /etc [1] as mentioned (although for other scenarios) in maintainers guide. So at that point any reinstall will just work, and no purge will affect it.
PS: other *ugly* option would be instead to make this other-package (mesa?) to replace in a maintainer script the content of this file with the fixed one, but really I don't want to go in that way.
[1] https:/