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 :)

Am 21.01.20 um 14:54 schrieb Robert Munteanu:

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: See https://build.opensuse.org/request/show/764079. kubectl is in kubernetes- client.

(the k3s package also provides a kubectl executable)

Would be great if we got some e-mail like the ones for new snapshot ou for failing packages also for package deletion.

I _think_ that there is a way for an RPM package to signal that it replaces another one, but for this scenario it was not done for some reason.

Yes, that is the Provides and Obsoletes headers. It will cause zypper to actively uninstall the old one and install the new package. https://en.opensuse.org/openSUSE:Upgrade_dependencies_explanation#Renaming_a...

On Tue, 2020-01-21 at 15:29 +0100, Richard Brown wrote:

On Tue, 2020-01-21 at 14:54 +0100, Robert Munteanu wrote:

...

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.

I _think_ that there is a way for an RPM package to signal that it replaces another one, but for this scenario it was not done for some reason.

Thanks, Robert

Having a Tumbleweed package with artificial conflicts with a package which was only created for SUSE Linux Enterprise doesn't make sense to me.

The package named 'kubectl' should have never slipped into Tumbleweed, 'kubernetes-client' has always been the proper, tested, well maintained, package providing the /usr/bin/kubectl binary for Tumbleweed and Kubic.

Especially considering that kubectl package had it's own specfile which, because of it's targetting a different distribution, didn't align with Tumbleweed/Kubic's way of packaging Kubernetes and totally broke building recently, the only sensible option was to drop the package from the distribution it never should have been in in the first place.

If I hadn't stopped building the kubectl package for Tumbleweed, I would have had to have 'fixed' the kubectl.spec so that it built for Tumbleweed.

And that would have screwed over the _intended_ users of the kubectl package..so that didn't make a lick of sense to me.

Sorry for anyone who got stung by this, but please, install the right package and I promise to never intentionally break the kubernetes- client that is actually maintained ;)

For me it was a just a little time looking for the right package. Thanks for the context and for working on making things right. Best, Robert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org