Delete requests need to be handled better
every now and then, we have issues with delete requests (mainly package renames)
just these days, we had a delete request for libapr1, combined with a submit request apr (providing libapr1)
The issue is that a 'delete request' has an immediate effect on '/snpshot' - so from the moment the delete request is accepted, libapr1 is no longer available in OBS to devel projects. Depending on the build status and openQA status of the snapshot that contains 'apr', it can be lengthy to get a binary libapr1 back in place for users to consume
delete requests are not the only things causing packages to disappear: removing of a 2nd spec file has the same effect:
recently, opencv was updated; it used to contain two spec files (opencv.spec and opencv-qt5.spec). The update elminiated the Qt4 support, so opencv.spec became the qt5 version and opencv-qt5.spec was removed.
Upon checkin, osc staging accept will drop the linked package opencv-qt5 - again, causing an immediate effect on /snapshot, where opencv (the qt5 variant) will only be available with the next snapshot being published
#2 Updated by dimstar over 5 years ago
Process wise, we could possibly solve it like this:
Before accepting a delete request, aggregatepac the existing binaries in the /snapshot repo
osc aggregatepac openSUSE:Factory pkg_to_delete openSUSE:Factory zzz_DELETED_pkg -m snapshot=snapshot,totest=totest
once aggregate is complete, build disable zzz_DELETED_pkg
accept openSUSE:Factory pkg_to_delete delete request
=> /standard loses the binaries (totest and snapshot retain them from zzz_DELETE_PKG)
once /standard is completed and moves to openQA, the binaries will be removed from /totest (by the pkg binary sync task) and then
once openQA test passes, /totest is synced to /snapshot - at this point, zzz_DELETED_pkg would have no binaries and the container could be deleted (a new bot to detect such empty containers could be written)
the name zzz_DELETED would be for 'us humans' to have all those delete requests grouped together
the same logic would apply for 'normal' delete request as well as 'deleting pkg containers of 2nd spec files'
#5 Updated by mlin7442 over 5 years ago
- Category set to Development
- Status changed from New to Resolved
- Assignee set to mlin7442
- % Done changed from 0 to 100
The feature is implemented and tested. What we are missing is a command to display "virtual accept delete requests", but that is not part of this ticket.