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
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
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.
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