[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c11 --- Comment #11 from Ludwig Nussel <lnussel@suse.com> --- (In reply to Alois Wohlschlager from comment #7)
What about enabling recommends, but shipping targeted locks to prevent installation of the worst offenders by default? That's what I currently do on my MicroOS system, since no-recommends is too barebones, and with my approach I get the bloat down quite a bit
If you have such a list already, a first approach could also be to try to simply file sr's to eliminate those recommends. That's what I did in the past with some packages and generally didn't get much pushback. Mind trying? :-) (In reply to Alois Wohlschlager from comment #10)
(In reply to Richard Brown from comment #8)
Locks are a terrible cludge that just result in broken systems
Ok, understood that this is not a generally applicable solution.
I'm all for installing all language patterns all the time, I'm not for installing GB and GB of random junk alongside them
Well, but recommends are not supposed to be "random junk" anyway, but rather "generally useful, but not strictly required". Where they do pull in random junk, I see basically three categories: 1a. Things that are generally useful on traditional systems, but not on MicroOS (e.g. pulling in YaST or Firefox from various desktop patterns). Does zypp have a way to express something like "Recommends: (MicroOS or yast2)"? If so, these could be used for a fix.
Yes that is likely possible via boolean dependencies. I wonder whether it's really needed though. I'd prefer to get rid of recommends. As OS vendor we have to decide whether a package is needed or not. A stricter definition of what is a mandatory part of the OS really helps in other areas too (eg transactional-update status).
1b. Compatibility-related, but rarely useful things, I mainly think of the kernel's "Recommends: kernel-firmware" here. This could be fixed the same way as 1a. 2. Things which are arguably plain bugs, such as pulling in Jupyter from some SELinux-related packages. These should be fixed anyway.
+1 -- You are receiving this mail because: You are the assignee for the bug.
participants (1)
-
bugzilla_noreply@suse.com