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.
Distinct copyrights were left as I do not wish to track down commit
history to ensure it properly documents the copyright holders. Also left
non-GPLv2 licenses and left bs_copy untouched as a mirror from OBS.
Already have a mix of with and without headers and even OBS does not place
on majority of files. If SUSE lawyers have an issue it will come up in
legal review for Factory.
Since the tool has been expanded to work on any repository, there are more
repositories that would want direct comments than devel. Set the value
to be devel for the openSUSE products which are the places where that is
desirable.
The rework includes a variety of changes:
- multiple actions per request supported
- automatically detecting "main" repo (useful for devel/home projects)
- full layered repository path state and published taken into account
- arbitrary repository name (ie. not just standard) supported
- intermediate results (used for staging) no longer accept (even if no
problems detected) until all layers are published
- no longer tied to staging process, but still supports staging workflow
- robust handling of repository state changes during review cycle
- multiple repositories supported for project_only output (ie. file name)
- project_only run supports any OBS project instead of only products
- maintenance_release requests supported with alternate staging approach
These methods provide for a generic place to store meta data related to
a project. For the time being, keep the original :Staging/dashboard
location for openSUSE products.
Given the slow migration of everything to the shared project config in
tools that change project contexts multiple times a consistent way of
accessing the config without forcing remote calls is needed.
The original case was to enable remote config, but in general and with
up-coming changes having the staging setting falsely set like this is not
ideal. Since the remote config is loaded via attribute this does not even
affect it anymore. The proper change is to make the "dashboard" container
configurable which is planned.
Otherwise, :Update projects match the primary product settings which
gives the wrong impression to tools as things like :Update:Staging do
not exist. Since :Update and other sub-projects are in a different phase
of development they should really have separate settings. :Ports however
does have stagings and in theory should act like parent product. If it
becomes desirable to split that can be done in the future.
Some policy settings related to ReviewBots likely are desirable to carry
over, but that can be resolved in follow-up as they are not currently used.
As the remote config is no longer optional for SLE and is utilized by
openSUSE to the point were it is dangerous not to load the remote config
it should be required. Currently only certain users call apply_remote()
while this will make it built-in during construction and thus makes the
usage consistent and no longer require StagingAPI.
Allows tool to be used on multi-action requests while still enforcing
the rule for Factory and Leap which should reject such requests due to
staging process.
Right now we require a Staging subproject to use staging plugin, which
is suboptimal especially for maintenance requests. The OBS attributes allow
to store the things right attached to the project - and the permissions
can be controlled in parallel to the maintainers right, which gives us
enough freedom
this architecture is also part of port, not only aarch64, and
we need architecture specific expansions, so extend default list
of architectures accordingly.
