`apt remove rpi-eeprom` seems wrong

[seamusdemora]

Describe the bug

I have an RPi 3A+, and an RPi Zero 2W; both run the 64-bit 'Lite' bookworm version of the OS. They do not use or need rpi-eeprom AFAIK. Trying to save some space, I was going to remove rpi-eeprom. Confusingly, it lists many additional packages that would be deleted - packages that are necessary and/or useful. Here's the dialog:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  bluez device-tree-compiler dos2unix flashrom iw libfdt1 libftdi1-2 libjaylink0 libossp-uuid16 libyaml-0-2 pastebinit
  python3-pycryptodome python3-toml raspi-utils-core raspi-utils-dt raspi-utils-eeprom raspi-utils-otp rfkill triggerhappy
  uuid
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  pi-bluetooth raspberrypi-net-mods raspberrypi-sys-mods raspi-config raspi-utils raspinfo rpi-eeprom userconf-pi
The following held packages will be changed:
  rpi-eeprom
0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.
After this operation, 125 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
$

Why are all these packages listed for immediate or eventual (via sudo apt autoremove) removal?

I use iw & rfkill regularly. I'm not familiar with most of the rest of these packages, but given that two I use are in the list, I'd be reluctant to go ahead.

pi-bluetooth?? ( I use Bluetooth for playing music) raspi-utils?? raspinfo?? (Why??? - a script required for submitting bug reports!)

In addition, there's this - which seems to run contrary to the dependencies selected for deletion in apt remove:

$ apt-cache rdepends --installed rpi-eeprom
rpi-eeprom
Reverse Depends:
  raspberrypi-sys-mods
  raspinfo

Steps to reproduce the behavior

On an RPi Zero, 1, 2 or 3 enter sudo apt remove rpi-eeprom

Device (s)

Other

Bootloader configuration.

rpi-eeprom-config output is empty on my 3A+ & Zero 2W systems

System

I don't think this is necessary for this issue.

Bootloader logs

I don't think this is necessary for this issue.

USB boot

I don't think this is necessary for this issue.

NVMe boot

I don't think this is necessary for this issue.

Network (TFTP boot)

I don't think this is necessary for this issue.

[lurch]

raspinfo?? (Why??? - a script required for submitting bug reports!)

raspinfo uses rpi-eeprom-update to display what EEPROM version you have installed https://github.com/raspberrypi/utils/blob/master/raspinfo/raspinfo#L287

[lurch]

pi-bluetooth?? ( I use Bluetooth for playing music)

$ apt show pi-bluetooth | grep Depends:
Depends: bluez (>= 5.50-1.2~deb10u1+rpt1), bluez-firmware, raspberrypi-sys-mods

$ apt show raspberrypi-sys-mods | grep Depends:
Depends: systemd (>= 230), gettext-base, raspi-config (>= 20220809), parted, fdisk, whiptail, uuid

$ apt show raspi-config | grep Depends:
Depends: whiptail, parted, lua5.1, alsa-utils, psmisc, raspi-utils

$ apt show raspi-utils | grep Depends:
Depends: raspi-utils-core, raspi-utils-otp, raspi-utils-dt, raspi-utils-eeprom, raspinfo (>= 20240402-4)

$ apt show raspinfo | grep Depends:
Depends: raspi-utils-core, net-tools, kms++-utils, rpi-eeprom, sudo, usbutils

[seamusdemora]

Mmm - The significance of your comments escapes me for some reason. Let me try asking another way:

If I apt remove rpi-eeprom - which seems to have no purpose on many RPi systems - why would:

• iw & rfkill be removed? (via 'sudo apt autoremove' - sooner or later that's gonna' happen)
• raspi-config be removed?

iw, rfkill and raspi-config all serve a useful purpose on RPi Zero, 1, 2 & 3 - whereas rpi-eeprom does not. So my question is, "Why are these useful programs being removed because a useless program is being removed?"

If the answer is that rpi-eeprom has functionality that I do not understand, then OK, so I shouldn't remove it.

[XECDesign]

raspi-config calls rpi-eeprom without checking whether it's installed, so it's a hard dependency. I agree that needs to be fixed.

Not sure about iw and rfkill. Are they actually getting removed or is apt just saying they're no longer required?

[seamusdemora]

raspi-config calls rpi-eeprom without checking whether it's installed, so it's a hard dependency. I agree that needs to be fixed.

Not sure about iw and rfkill. Are they actually getting removed or is apt just saying they're no longer required?

I don't think it makes any difference... it says "no longer required". AIUI, that marks the package as "to be removed" by 'sudo apt autoremove' - which will delete the package whenever it is run... if not immediately afterwards, then at some point in the future.

[XECDesign]

I don't think it makes any difference

It makes a difference in understanding why it's happening. And sorry, just noticed you included that information in the first post anyway.

When you run apt install package_name, apt remembers that you installed that package manually and marks it as such. Any dependencies pulled in by package_name are marked at having been installed automatically.

apt will never autoremove packages which were installed manually. However if you manually remove package_name it will detect that some or all of the dependencies that were installed automatically are no longer needed.

In this case, it sounds like rfkill and iw were installed as dependencies of something. Where I'm going with this is that if you're seeing that apt is suggesting a package is no longer required, you can apt install or use apt-mark manual to tell apt that you actually want that package.

As far as raspi-config goes, we can add a "is rpi-eeprom installed?" check when entering the boot order config menu and notify the user if there's an issue. After that, this issue should go away.

[lurch]

Mmm - The significance of your comments escapes me for some reason.

Apologies if my comment was a bit obtuse. I was trying to demonstrate that pi-bluetooth depends on raspberrypi-sys-mods, which in turn depends on raspi-config, which in turn depends on raspi-utils, which in turn depends on raspinfo, which in turn depends on rpi-eeprom. Therefore when you try to apt remove rpi-eeprom, apt also uninstalls all the packages that depend on rpi-eeprom, which ultimately also includes pi-bluetooth.

(As to why those particular package-dependencies exist, I have no idea. So you'd have to do your own research if you're really curious.)

As far as raspi-config goes, we can add a "is rpi-eeprom installed?" check when entering the boot order config menu and notify the user if there's an issue. After that, this issue should go away.

@XECDesign according to apt show raspi-config, there isn't a direct dependency of raspi-config on rpi-eeprom; but as illustrated above the dependency-chain is actually raspi-config -> raspi-utils -> raspinfo -> rpi-eeprom.

[seamusdemora]

As far as raspi-config goes, we can add a "is rpi-eeprom installed?" check when entering the boot order config menu and notify the user if there's an issue. After that, this issue should go away.

I think that would be an improvement over the current situation.

WRT iw and rfkill: Those are both part of the default install; i.e. you get them when you install the OS. I've never seen such errant behavior from apt, so I'll assume that it's caused by a flaw in RPi's "package creation procedures".

[vintozver]

$ apt info raspi-utils Description: Collection of scripts and simple applications This is a meta-package that installs all of ytilities

$ apt rdepends raspi-utils raspi-utils Reverse Depends: Depends: raspi-utils-dbgsym (= 20240402-3) Depends: rpi-eeprom Replaces: raspinfo (<< 20240402-4) Breaks: raspinfo (<< 20240402-4) Replaces: raspi-utils-otp (<< 20240402-4) Breaks: raspi-utils-otp (<< 20240402-4) Replaces: raspi-utils-eeprom (<< 20240402-4) Breaks: raspi-utils-eeprom (<< 20240402-4) Replaces: raspi-utils-dt (<< 20240402-4) Breaks: raspi-utils-dt (<< 20240402-4) Breaks: raspi-utils-core (<< 20240402-4) Replaces: raspi-utils-core (<< 20240402-4) Breaks: libraspberrypi-bin (<< 20230123-1) Depends: raspi-config

I think the fact that rpi-eeprom depends on the "meta-package that installs all of ytilities" is way overreaching. rpi-eeprom should only depend on what it needs to have (flashrom, raspi-utils-eeprom, etc.)

[timg236]

For the most part rpi-eeprom can have weak (non-apt) dependencies but polishing this to make it easy to remove rpi-eeprom is a pretty low priority. Things make change in the future as a result of pi-gen work which may involve unpicking some of the raspi-config dependencies.

[timg236]

Removed unhelpful comments, as final warning before blocking user

[pelwell]

We've already acknowledged that things could be improved, but the fact that you are the first person to report this issue in however many years says something about its relative importance.

[vintozver]

I would like to add some "value" here. I do have at least 2 setups where I have "live production" (with root overlayfs) + rescue (minimal system to mess around with that "production"). Using tryboot mechamism, if need to update the "live system". Works pretty good for me. However, the presence of rpi-eeprom in both live and rescue adds extra 125M (give or take, that's how fat the rpi-eeprom package is when installed, right?). I would be happy to see the rpi-eeprom package only on the "rescue" system, where the actual update of eeprom would make sence.

I also have at least 4 Pi3B+ units, where eeprom is not applicable.

Other than being an eyesore, and having extra 125M when not really necessary, it does not affect overall functionality. However, being an "embedded", "lightweight", "compact" would also imply "necessary and sufficient".

If Windows downloads 5Gb to update Bluetooth drivers, it's majorly sufficient, but is that really necessary?

[timg236]

@vintozver To expand on my previous comment we are looking at dependencies for rpi-eeprom and other utilities specifically to make it easier to make small, embedded images e.g. see pi-gen-micro https://github.com/raspberrypi/pi-gen-micro. Part of that is analyzing the dependencies between the utilities packages, switching some dependencies to be "recommends" or refactoring packages. However, since this is quite complex we are looking at the overall architecture first and avoiding doing point fixes to individual packages.