There is no product that wants all suggests for all products on all groups,
so the only product left that wants to have suggests is Tumbleweed for the DVD
pattern
To solve the suggests we run a global transaction on the
result + its suggests to determine packageand supplements.
To avoid problems (in general) we discard obsolete and conflicts
in packages - so we can have product groups with conflicting packages
and still get the additional supplements
The heuristic calculating the product family doesn't really work
for ports, so give the tool some hints in the config. And as 15.1
doesn't have a baseurl yet, we need to give 15.0 one specifically.
The config default for pseudometa package (00Meta) does not
exist for Tumbleweed, so we need to add an override for :ARM
to contain the proper information so that the publishing
logic doesn't stop. Also update correspondingly for Leap
reduce() is no longer part of python core, but we don't
need it actually - since we use remote configs, we have
no more required settings (otherwise we put them in remote).
And to quote the python docu as I found it interestingly
proving my own impression of this code:
> Removed reduce(). Use functools.reduce() if you really need it;
however, 99 percent of the time an explicit for loop is more readable.
Without this, the relative rarer types of requests seen in projects with
staging and handled by list command will be included in staging proposal.
However, since they are not stageable the select operation will fail. This
change ensures that a filter is always present when stageable is True to
exclude non-stableable requests. The list command sets stageable to false
in order to list out the non-stageable requests of interest.
This was not observed in openSUSE since the main non-stageable request was
change_devel and that was exluded in StrategyNone. That filter could be
replaced with the stageable filter, but having an always on filter seems to
make more sense since generally operating in one of two modes.
We can't generally assume ISOs can be fetched from backend (we can't
have this on IBS), so publish it - and disable the actual publishing
on the staging backend of OBS
Submitters complain more and more about the spam they're getting from
staging projects - and we rather leave that weapon for actual feedback.
One especially annoying case is if a package is added to one staging project
and then later moved to another, the submitter will receive notifications
of all kind of bots and actions for both staging projects.
