On Tue, 2020-01-21 at 10:08 -0300, Luiz Fernando Ranghetti wrote:
Em ter., 21 de jan. de 2020 às 09:49, Christophe Giboudeaux
escreveu: On mardi 21 janvier 2020 13:22:38 CET Michal Hlavac wrote:
Hi,
I would like to ask where can I find some info about package removal reason? I've searched bugzilla and didn't found any of it.
thanks, m.
See https://build.opensuse.org/request/show/764079. kubectl is in kubernetes- client.
(the k3s package also provides a kubectl executable)
Hi,
Would be great if we got some e-mail like the ones for new snapshot ou for failing packages also for package deletion.
The question there is at what point should that email be sent out? When the del req is created? When the package is removed? when the snapshot with the package no logner present is being published? You can get a list of currently running delete requests: osc rq list openSUSE:Factory -t delete so at this very moment, there are 23 delete requests in the queue. Some of them are follow-ups to the 'build fail reminders' - stuff still not being fixed, some are consequences from the minimizing python2 footprint. And some simply because maintainers thing it's no longer sensible to have this package in the distribution. The case for kubectl was not even the same, as there was no delete request involved: kubectl was a 2nd spec file inside the kubernetes package. the 'package container' in openSUSE:Factory actually still exists, but the build is marked excluded (not being built for openSUSE) - the maintainer clearly declared that the functionality of this package is provided by kubernetes-client; kubectl was according to him not ever meant to be in Tumbleweed, but purely targetting backports for older distros. Sometmies it's even just subpackage of a package disappearing which causes the same uproad, becuase somebody lost his favorite feature. Again, that would be a simple .spec file update' and a regular submission - just a package less to be built. No delete request involved, yet the result is a binary package less. Another case: libisl19 has been removed from the distro, as the library changed the so-version to 22 - which means libisl22 appeared in its place. Is this worthy to be sent in a mail about a package drop for libisl19? If we can come up with the correct requirement to produce such mails, I'm open to it. But I hope the above already gave some clues thatit might not be that easy to come up with the requirements. Cheers, Dominique PS: Ieven more like code proposals :)