package/pkg-generic: add support for uninstalling packages

Hello,

Quoted 4 lines · Shubham Chakraborty

I didn't consider reverse dependencies. The scenario you described (uninstalling openssl breaking ntp) is a
serious problem that makes the current implementation unsafe.

Quoted 4 lines

I see a few potential approaches to address this:

1. Add dependency checking that refuses to uninstall if reverse
dependencies exist (similar to package managers like apt/dnf)

This would make the feature useless for a significant number of packages I'd say.

Quoted 3 lines

2. Implement cascade uninstall (uninstall the package and all its
reverse
dependencies)

This would probably be the logical thing, I guess?

Quoted 8 lines

4. Simply document this as a "use at your own risk" feature for
advanced
debugging scenarios

I wanted to ask: would any of these approaches be acceptable for Buildroot? Or is the fundamental issue that without proper
dependency tracking during uninstall, this feature is too dangerous to include regardless of warnings/checks?

This has so far been the project's opinion on this topic. But nothing is set in stone forever, so we can always revisit/rediscuss things.

Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training
https://bootlin.com

Hi Thomas, Shubham, ALL,

Quoted 9 lines · Thomas Petazzoni

Hello,

Quoted 4 lines · Shubham Chakraborty

I didn't consider reverse dependencies. The scenario you described (uninstalling openssl breaking ntp) is a
serious problem that makes the current implementation unsafe.

Quoted 7 lines

Quoted 4 lines

I see a few potential approaches to address this:

1. Add dependency checking that refuses to uninstall if reverse
dependencies exist (similar to package managers like apt/dnf)

This would make the feature useless for a significant number of packages I'd say.

In most cases, exactly these reverse dependencies make removal of the package desirable. Testing with and without sometimes needs manual intervention. Also I prefer clearing up the mess after testing to doing a full rebuild: it's less time consuming.

Quoted 6 lines

Quoted 3 lines

2. Implement cascade uninstall (uninstall the package and all its
reverse
dependencies)

This would probably be the logical thing, I guess?

Nice to have, but is it worth the effort? This is not a tool for everyday use, and most people will know what they are doing.

Quoted 4 lines

Quoted 4 lines

4. Simply document this as a "use at your own risk" feature for
advanced
debugging scenarios

Quoted 8 lines

Quoted 5 lines

I wanted to ask: would any of these approaches be acceptable for Buildroot?
Or is the fundamental issue that without proper
dependency tracking during uninstall, this feature is too dangerous to include regardless of warnings/checks?

This has so far been the project's opinion on this topic. But nothing is set in stone forever, so we can always revisit/rediscuss things.

I used to delete files manually, until I discovered the central packages-file-list*.txt files, and have been using a similar Python script for a few years. Shubham's approach to use the package based lists is better.

Including the script as a build target is optional.

Quoted 5 lines

Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training
https://bootlin.com

Kind regards,
Andreas