Implementation virtually accept the delete request, the delete request will be
added another delreq-review review and also wipes the binary in the main
project, the backend will sync 'nothing' to ToTest and Snapshot after all. Once
all repository has no binary then remove the package in real.
Wihtout selected_requests then that adi staging project is an empty project,
adi command should clean it up rather than go through the logic to check the
project status. Since we have introduced a kind of frozenlinks adi staging,
the project status might be build broken or so but it doesn't have any request
staged in that staging actually, those kind of projects must be deleted.
If users build against an adi project OBS will refuse to delete, but in
that case breaking other projects is fine as the branches should only be
used to work on fixes seen in adi stagings.
See #1142 for an example, details, and discussion.
The variable project might got changed through
map_ring_package_to_subject(), according to release process, we have to
given the origin project path to set_review() always.
* Create sub-package in case an adi request is multiple specfile package
* Use the consistent workflow in rm_from_prj(). The main package must to
through map_ring_package_to_subject() like what it did in
submit_to_prj()
The new logic is introduced, the description is below:
* If adi package: return sub-package list according to the specfiles
of main package.
* If ring package: return sub-package list by showlinked call and the
sub-package must be in another ring.
* The others: return empty list, no reason to return anything or even
checking it in the devel project. Otherwise selecting a non-ring
package to a letter staging probably would created unneededsub-package.
Currently none of the SUSE:* projects have :DVD subprojects and there is
no way to know short of checking if the project exists. This allows for
len(staging-dvd-archs) to be used to know.
Make sure the links of package in Rings must are valid before processing,
otherwise someone had package linked to the Ring package in somewhere else than
Rings will breaks select/delete/rm_to_prj, ie. _link will be created. Therefore,
only return the candidate if it has proper linked from another ring and have
different package name.
This allows for cases where the requested project was something like
openSUSE:Leap:42.3:Update and the returned project was openSUSE:Leap:42.3.
With this change the fallback will be triggered and the global maintainer
will then be used.
