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
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
> 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,
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
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
On 2021/02/16 00:58, Dominique Leuenberger / DimStar wrote:
* The snapshot is going to be large, in the number
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?
Simon Lees wrote:
2. The following repo  contains multiple rpm
highest version one will be capable of installing rpm 4.14.1
from Leap 15.0  otherwise upgrades wouldn't have been
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.
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
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
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.
Simon Lees wrote:
From there you can reupdate everything or rebuild rpm
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.
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.