23 Feb
2021
23 Feb
'21
09:46
On 2/23/21 5:31 PM, L A Walsh wrote:
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.
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).
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 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?
Simon Lees wrote:
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.
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.
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:
Shouldn't be, the openSUSE packages should provide all the migration
needed for this if you install them in the right order.
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. Simon Lees wrote:
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
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.
http://download.opensuse.org/distribution/leap/15.0/repo/oss/x86_64/rpm-4.1…
---
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.