Comment # 11 on bug 1196547 from Ludwig Nussel

(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