At least "minimal" must be vital, because it's required for a functional system. For example, we might create new packages in the future which are required for the multi-user system and are part of the minimal set, so it's important that users don't remove set-minimal to ensure they get those new packages. For the other sets, it's debatable whether they should be vital or not, but let's start out with the assumption that if the user installed a set, they should have to have to explicit request it be removed. This means if, for example, they install set-devel, then remove lldb, pkg won't remove set-devel and cause the next "pkg autoremove" to remove everything else that was in set-devel. We might want to adjust this later (or possibly adjust the behaviour of pkg(8) itself) based on user feedback. While here, fix a typo in the description of the devel set. Suggested by: bapt MFC after: 3 seconds
Details
Details
- Reviewers
kevans - Group Reviewers
pkgbase - Commits
- rG8f1cddbf0c9a: packages: Mark all sets as vital
rG9537aa02f404: packages: Mark all sets as vital
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 67106 Build 63989: arc lint + arc unit
Event Timeline
Comment Actions
I think they should all be vital, in the sense that if you've installed that metapackage then you don't want your system to ever remove it without very explicit confirmation, no?
Comment Actions
these sets are different because they're required for the operating system to work. that is, if you install FreeBSD-set-devel, then remove FreeBSD-lldb, which also removes FreeBSD-set-devel, this means you won't get any future set-devel packages, but you explicitly chose that, so it's fine, and your system will still work.
but if you do something that removes FreeBSD-set-minimal, and then we decide to move (say) /bin/sh to a new FreeBSD-sh package, this will absolutely break your system next time you reboot. this is almost certainly user error, so we should just disallow that, and the user can override it if they know what they're doing.
in other words, this is intended to prevent the user from inadvertently breaking the system, but we still assume the user actually reads the proposed plan from pkg before pressing y.
Comment Actions
I think my complaint is that, iirc, all of the metapackage dependencies are marked as automatic. As soon as they break the set as you suggest, the remainder would be subject to autoremove
Comment Actions
right, but if you run pkg remove FreeBSD-set-devel followed by pkg autoremove, don't you expect all of clang etc. to be removed?
if the user does this by accident then runs pkg autoremove, they will see it's trying to remove FreeBSD-clang or whatever and can abort and rectify the situation.
Comment Actions
I would expect that, yes, but that isn't the scenario you proposed.
if you install FreeBSD-set-devel, then remove FreeBSD-lldb, which also removes FreeBSD-set-devel, this means you won't get any future set-devel packages, but you explicitly chose that, so it's fine, and your system will still work.
If I remove freebsd-lldb, which removes set-devel, the next auto remove will wipe out everything else in set-devel that I presumably wanted to keep.
Comment Actions
Yeah, I'm happy with that, thanks. I recognize this is maybe not ideal for more flexible system construction (piece together your own based on a set and removing some), but IMO we should err on the side of caution and consider whether we can do something to enable better behavior with the final form of pkg groups.
Comment Actions
i think the real problem here is that pkg(8) just doesn't handle this very well, for which i've filed https://github.com/freebsd/pkg/issues/2517 upstream.