On 9/7/21 23:25, Ben Greiner wrote:
Am 07.09.21 um 12:59 schrieb Simon Lees:
SLE got an update from 10.X to 20.X during 15-SP1 with a couple of updates since one was in 15-SP2, it shouldn't be too hard to take the sources for that package and ship them as an update for Leap unless there is a really good reason not to have a newer version like it would break lots of things for lots of people, but it already seems broken.
I have no insight into why SLE15-SP1 got that update, but I would not consider pip broken for Leap <= 15.2
If you use pip, you have already decided to populate either a user site or a virtual environment. If that is the case, you can always use the system pip 10 to install a more recent pip into the user site or venv.
Yes but if most people are required to use pip to update to a newer pip because the old one doesn't work with many libraries anymore I'd consider that broken and certainly worth upgrading, at an extreme point if pip 10 could no longer update to the latest version this would be very very broken. Being broken in such a way as described above would be more then enough reason to ship a maintenance update to a newer version. On the other hand if almost all pypi packages still work with pip10 then it might not be worth updating because of the risk of it breaking something.
System packages normally don't need pip on runtime. If there was one in Leap, which does not work with pip10, it would have been broken from the beginning.
Yeah this I am well aware of, I was more thinking of the risk that if we upgrade from pip10 to pip20 there is a chance that it will break a users setup or workflow that was created with pip10. Again if we believe the risk of a pip10->pip20 update breaking existing pip setups is really low then it would make sense to do the update because it will obviously benefit some users. While for many things we are very conservative on our update policy with leap if something is pretty much at the point of no longer functioning properly we do have scope to update it, especially in cases like this where the package isn't using the sources from SLE. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B