[Mageia-dev] painful discussion n°1: debloating

Sat Apr 7 17:38:39 CEST 2012

If thos of you lucky enough to have missed the beginning of the story, 
+here are the importants parts:
+- first round: bug #4357, still marked as release blocker (despite a bit 
+excessive IMHO)
+- second round: discussion on -dev, archived here:
+https://www.mageia.org/pipermail/mageia-dev/2012-March/013342.html
+
+The whole issue turns around the unfortunate consequence of adding new 
+dependencies, for various reasons, between packages and in installer: 
+bloated minimal installation. In this case, this is about a specific 
+*soft* dependency from gnome-keyring to seahorse, which has painful 
+consequences, as outline by TV in comment #5 of the original report.
+
+Suggestion sofar for this initial problem have been suggested:
+1) move the gnome-keyring -> seahorse soft dependency either in 
+task-gnome, or task-gnome-minimal
+2) turn the mandatory dependency between libgnome-keyring to 
+gnome-keyring into a soft dependency
+3) remove the dependency on a gnome component from the KDE category in 
+the installer
+
+But sofar, nothing was done AFAIK, the bug is still open.
+
+ From my own personal and biased reading, solution #3, makes sense. 
+Actually, it would only adress a part of the problem, as installing the 
+distribution doesn't mandatorily means 'running the installer'. chroot 
+installation, for instance, or automated installations, are not affected 
+by rpmsrate, but still face side-effect of those nasty 'useful' 
+dependencies between packages. Of course, this only concern expert 
+users, who usually know about --no-suggest urpmi option.
+
+Solution #1 would also make some sense for me. As pointed out by TV, you 
+don't mandatorily install gnome-keyring because you need it, but because 
+you don't have the choice, and something else introduced it without 
+asking you. That's a bit difficult to argue in this case that you may 
+need seahorse to manage your keys, merely because you problably never 
+intended to store keys anyway. So I'd also implement this solution, 
+despite once again, if you really care, you may use --no-suggest also.
+
+Solution #2, tough, would introduce some precedent. AFAIK, all gnome 
+libs unfortunatly require their binaries to be installed alongside to be 
+used, for I can't remember technical reason. So, I'd rather reject it.
+
+To summarize it:
+- has anyone any opposition to remove the totem-mozilla - KDE 
+relationship in the installer ?
+- Olav (or anyone else), do you have any objection to *also* move the 
+soft dependency from gnome-keyring to seahorse to either task-gnome or 
+task-gnome-minimal ?
+
+More generally, we still lack a clear view of interactions between 
+choice hardcoded in installer rpmsrate, and two different kind of 
+dependencies between packages. And a general policy on this kind of 
+issues, aiming a correct balance between 'avoinding poor users the pain 
+of installing additional stuff themselves' and 'keeping system minimal'.
+-- 
+BOFH excuse #189:
+
+SCSI's too wide.
+