Hi Thorsten, * Thorsten Glaser <t...@mirbsd.de> [200517 04:15]: > I’ve noticed that fdisk will now be autoremoved on many systems > because the dependencies on it are gone from everywhere else.
Indeed. I've had to remove Important: yes because of a weird apt/piuparts interaction, but that would have been a stopgap at best. > While this is probably ok for new installations, existing systems > might… find this not so much agreeable. > > I’d suggest running 'apt-mark manual fdisk' in the upgrade case > in a maintainer script, but since the package database is locked > during their execution I know this isn’t doable. > > Any better ideas? I gave this some thought, and now I'm not sure autoremoving fdisk is such a bad idea. It's suprising, and to my server-focused eyes certainly disturbing. But so are many other packages that we no longer install by default -- telnet being one of those I'll always miss. Also, over the past decade or so the recommended tool for partitioning has changed a number of times; we went from fdisk to parted to gdisk and maybe now that it again understands enough, to fdisk. However, I suspect desktop users will never want to interact with fdisk, but would use the GUI tool of the day to format their USB keys. If we'd had a fictional "task-server" task package (like we have task-desktop today), I'd suggest it should depend on fdisk. But we don't, and it appears, we don't need to have that. (It certainly would not help me.) fdisk will be one `apt install` away if it gets autoremoved; once you need a partitioning tool you can pick one again, preferably fdisk ;-) TL;DR: I think it is okay to have fdisk autoremoved for almost everyone. Thanks for the report! Chris (I've bcc'ed the Grml team, giving them a heads up. Other Debian based Linux Live systems should probably also check their dependency lists.)
