On 2/23/21 5:31 PM, L A Walsh wrote:
On 2/22/21 1:47 PM, L.A. Walsh wrote:
If someone has a pre-4.14 rpm, then they can't upgrade to suse's current packages. They also cannot build or install an rpm>=4.15...
Simon Lees wrote: This is simply not true, [it's just that]... if you don't have rpm 4.14 or later on your machine its no longer in a state we support.
How does this not seem like doublespeak, or speaking with a forked tongue?
If someone doesn't already have their "upgrade ticket" in place, they can't get one. Instead, they should use os-reinstall media to reinstall all packages? I.e. upgrading to 4.14 and then 4.15 isn't supported. So how is that not the same as "not being able to upgrade to suse's current packages"?
As I said before, if you are going to have an upgrade path that breaks if you don't upgrade within a specific window, then I would point out that the upgrade path is broken. My machine was offline from for ~4 months of last year. Before that time I could download packages and none of them required 4.15 to upgrade. After
In that case something unusual was going on with your machine, generally our supported upgrade is two generations of SUSE products, we are still testing upgrades from 42.X and 15.0 which puts the supported upgrade path in the category of years rather then weeks or months, you mentioned in another thread you ended up with an old version of RPM, I was just trying to help you get a working version back.
otherwise tumbleweed users wouldn't have been able to upgrade similarly Leap users wouldn't be able to migrate to tumbleweed (which they can) as Leap still has 4.14 which first came around early 2018.
The gap isn't about me building rpm's on my machine for someone else's machine, but is about me building rpm's for my machine. The problem is that I can't build+install the current rpm to install on my system.
Unfortunately and you really only have two options, 1. use the upgrade function on the installation media,
I tried one Dominique used. It was going to replace about 240 packages, remove about 40 others and add 10-15. One of those was glibc, which would leave any un-upgraded package, _stranded_, by default. Now she announces another rev of glibc, "requiring", probably another 200+ packages.
Others here have claimed that a newer version of glibc should support older SW as well:
On 2021/02/16 23:30, Thorsten Kukuk wrote:
Everything compiled against glibc 2.x still works with glibc 2.33 today. The glibc developers are doing really a great job in keeping the ABI stable. There is absolute no need to keep older glibc versionsin parallel.
However, Dominique says the large number of packages in Feb-12's release are because of all the packages linked with glibc and it being upgraded:
On 2021/02/16 00:58, Dominique Leuenberger / DimStar wrote:
* The snapshot is going to be large, in the number of ackages to 'update' (mostly rebuild counters) and thus lso megabytes. * The snapshot is the first to be based on glibc 2.33
So, which is it? If glibc is binary compatible, then why do so many packages need immediate upgrade when glibc is upgraded?
In Tumbleweed we take a pessimistic view of the world and rebuild and publish a new version of any package if one of its dependencies change regardless of if it does or doesn't break binary compatibility. The release managers like to rebuild the whole distro a couple of times a year to be safe, glibc provides a good time to do this as we would have been rebuilding most packages anyway. We don't do this for updates in released products such as SLE and Leap however, there we have very strict policies on updates being binary compatible. In short they don't need to update but its a design decision that they do, it saves effort in the case that a non binary compatibility breaks in a way that would affect things (again we don't allow this in Leap / SLE updates).
Simon Lees wrote:
2. The following repo [1] contains multiple rpm packages, the highest version one will be capable of installing rpm 4.14.1 from Leap 15.0 [2] otherwise upgrades wouldn't have been possible.
Perhaps it's like the latest update -- all packages w/a glibc dep, are getting replaced -- do they need to be replaced or is this just chasing the latest update? But the reason the updates were possible is that for some window, there were rpm versions that could handle old and new. That window has passed. But that's the problem -- the rpm-binary that could speak both formats should have been statically linked so it could run on both. and would be runnable in the future. Even building an rpm on the Musl libc variant would work. FWIW, a static binarywith musl (if I don't have the name wrong), isn't hard to setup and takes about 1/6th the space.
This has been discussed in the past, from an openSUSE perspective we would be far more interested in a statically linked zypper which has fun issues and isn't really needed in the end because we provide working upgrade paths for people on standard systems.
I have 4.11.3 on my system and have tried installing 4.14.1 and then tried building it -- same for 4.15.1 -- though it's in the new binary encoding, and won't be loaded by rpm's under 4.15 and 4.15
but have you tried using the 4.14.1 to install the 4.15 and then the 4.15 to install the now current 4.16. Then you can use 4.16 to build and install whatever you'd like.
Simon Lees wrote:
From there you can update to the latest rpm provided in Leap 15.2 and then onto rpm 4.16.0 which is now the version in tumbleweed.
This matter is complicated by RH and Suse having some binaries in different locations, as well as moving the rpm-DB and changing to a new DB format.
Shouldn't be, the openSUSE packages should provide all the migration needed for this if you install them in the right order.
Simon Lees wrote:
From there you can reupdate everything or rebuild rpm from source or whatever you would like. If you are unwilling to try those things there isn't really anything we can do to further help you with your issues.
1. http://ftp5.gwdg.de/pub/opensuse/discontinued/update/leap/42.3/oss/x86_64/
2.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/rpm-4.14...
---
Another FWIW, I working on my download script being workable with leap-15.0 (who knows, maybe I'll throw in leap-42.3 if I get the former working cleanly. I had to cook my own script for TW due to it changing package versions daily. with leap and predecessors, I could d/l binaries from the whole leap-42.3 window and easily integrate them, but w/TW, being released daily, I need to pull down the the file+ver list of the day and verify I get all the src+oss+non-oss associated with a 1day window and ensure I have the exact rel #'s from that 1 day window to ensure it all works together. That script I got working in the past few weeks. Just started on upgrading it for leap last week, that may take a while again, as I do get distracted and have other projects/work I need to do at the same time, and my clones' organic brains are still slow to update. As soon as they/I get the nextgen brains in w/fiber interfaces, that work should go much faster.. ;^/. Sigh...
Meanwhile, for key pieces of SW like a dual-protocol rpm, they really should be statically built-to-last.
Well the supported way to update a system is `zypper dup` we will make sure that works there should rarely be a need for an openSUSE user to call rpm directly, especially when installing / removing / upgrading packages. -- 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