No longer compare against the target project's cycle, but just against
a configured list of package names. This way we're not bound to
refreezing stagings if we reduced cycles and it's clearer to the
operator what happens and how to react to it.
The author was attempting to port for python3, but changed the meaning:
- print ' ', line
+ print(' ' + line)
The first prints " $line", while the second:
" $line".
This changes console output from:
science
666254 libArcus-lulzbot -> delete (delete request)
3 more users
back to:
science
666254 libArcus-lulzbot -> delete (delete request)
3 more users
(ignore lines up and standard double space indent used)
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.
