Bug 1383155 - [RFE] make groups to control dependencies
Summary: [RFE] make groups to control dependencies
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-10 05:07 UTC by Matthew Cline
Modified: 2017-06-07 08:14 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-07 08:14:44 UTC
Type: Bug


Attachments (Terms of Use)

Description Matthew Cline 2016-10-10 05:07:19 UTC
/etc/dnf/protected.d only comes with a single protected package, dnf (and systemd seems to be built-in protected).  However, depending upon your system, there's a lot of other packages that should be protected.  For instance, considering my installation:

* I have an x86 64 bit system which uses GRUB, so grub2, grub2-efi and shim packages should be protected, since if they're removed I'll be unable to boot my machine.
* I update dnf via remote repositories connected to over the network, so networking packages like NetworkManager and net-tools should be protected, since if I remove them then I'd be unable to add them back in.
* Further, I use a wireless USB adapter to connect to the net, so wpa_supplicant and wireless-tools should be protected, as well linux-firmware, which contains the driver for the wireless adapter I use.

It would be nice if there was a tool which automatically figured out stuff like that and would spit out a list which could then be put into a protected.d conf file.

Comment 1 Igor Gnatenko 2016-10-10 06:10:59 UTC
(In reply to Matthew Cline from comment #0)
> /etc/dnf/protected.d only comes with a single protected package, dnf (and
> systemd seems to be built-in protected).  However, depending upon your
> system, there's a lot of other packages that should be protected.  For
> instance, considering my installation:
> 
> * I have an x86 64 bit system which uses GRUB, so grub2, grub2-efi and shim
> packages should be protected, since if they're removed I'll be unable to
> boot my machine.
Problem here is that other people might have lilo/uboot/systemd-whatever_bootloader. They might change them.
> * I update dnf via remote repositories connected to over the network, so
> networking packages like NetworkManager and net-tools should be protected,
> since if I remove them then I'd be unable to add them back in.
Same here.
> * Further, I use a wireless USB adapter to connect to the net, so
> wpa_supplicant and wireless-tools should be protected, as well
> linux-firmware, which contains the driver for the wireless adapter I use.
This is basically same.
> 
> It would be nice if there was a tool which automatically figured out stuff
> like that and would spit out a list which could then be put into a
> protected.d conf file.

I would say that we should make groups to have really protected packages. E.g. you install group "Workstation" which has Req: NetworkManager. So if you will try to remove NM, then you will be warned in the terminal.

Comment 2 Honza Silhan 2016-10-17 11:42:22 UTC
This RFE is really low low prio. If anyone else finds it useful, please CC and write a comment. Thanks.

Comment 3 Jaroslav Mracek 2017-06-07 08:14:44 UTC
I am really sorry but the original request cannot be delivered, because it is to user specific. There is a number of users that use very special set of packages and auto-generation of protected packages could brakes their work-flow. But every user can add his own list of packages into /etc/dnf/protected.d/<my_esential_packages>.conf file. 
Other proposed solution will not work ether, because again we will only guess what user wants. Like in case when user wants to use alternative functionality provider and wants to remove the provider from protected group.
Therefore I am closing it.


Note You need to log in before you can comment on or make changes to this bug.