On 2021/02/16 14:25, John Paul Adrian Glaubitz wrote:

...

I can take programs in Win from 10-20 years ago and they still work on a current day win because the OS loads library updates by version.

That's actually not true. Microsoft fixed a lot of bugs in their ABI over the time and dropped support for various older ABIs when they switched to 64 bit Windows or rewrote fundamental subsystems such as the graphics or sound stack, so that a lot of older programs don't work anymore.

I have MANY programs on my machine from Win XP days and probably a few from before and they still run. You are talking about programs that did their own thing w/the underlying HW -- many graphics programs didn't use the DirectX interfaces or opengl, but ones that did still run. Problems with old programs that were tied to hardware access are not a software-library-versioning problem, so please don't confuse the issue.

I think there even used to be a WINE on Windows port to address this issue and allow older Windows applications on newer versions of Windows.

Win7 came with a WindowsXP mode for the few programs that wouldn't work on newer version -- mostly ones that did thing using the 16-bit API that WinXP supported from Win95/98 days. I did say 10-20 years ago, not 25 years ago -- but those were because of changing HW, not because new library versions were incompatible.

...

Unix did the same -- but move to linux, and vendors got lazy and stopped using the correct versions to link with. Why? And how can this be fixed?

Actually, you can run 30-year-old binaries on a current version of Linux as long as you provide the necessary shared libraries or the application is statically linked since the Linux kernel guarantees to never break any userspace code.

--- Actually you are bullshitting us. There was no linux 30 years ago this month and V1.0 didn't come out until 1994. I'm pretty sure it wasn't binary compatible. Even when the linux kernel doesn't break user space code, glibc will refuse to run on older kernels. Old apps need to keep around the old libs. But then you are saying what I said in saying that users need to provide the libraries -- it's not handled by the OS and that makes running older programs unviable as package managers like rpm, remove older versions of libraries when you upgrade, making it very difficult to support older progs that worked w/older libs. That said -- most linux progs don't link to shareable object libraries even using the major number. Some do, but when did you see someone linking with glibc-1 vs. glibc-2. As for glibc compat, theoretically under semantic versioning, glibc 2.1 should be compat with glibc 2.33 -- so again, I ask: Why are all the apps in TW being rebuilt w/new glibc vs. being replaced as those apps are updated?

On Tue, Feb 16, L A Walsh wrote:

This is another example of a snapshot that will make package upgrades impossible w/o a full rebuild -- for a similar reason rpm 4.15 can't be built by rpm 4.14 or before. rpm 4.11 ships with rpmlibs-v3, while rpm4.15 ships rpmlibs-v9. The libs jumped 6 versions while rpm went up 0.14.

The windows of what binaries work with what date of TW is too small.

Is suse supporting this model for enterprise customers? I can't believe they would tolerate it.

Seems you mix up Tumbleweed as rolling release distribution with openSUSE Leap/SLE as stable distribution. In the first case, you have always the newest stuff, in the later case, you have stable interfaces, with the drawback, this is old code. Tumbleweed tries the best to provide all the new, shiny features in a stable way, Leap and SLE tries eveything to stay compatible without providing all the new features.

It used to be (before all binaries had version numbers included in their binary), that you could upgrade across versions for most things, or install multiple versions of some libraries for various programs.

You can do that still today. If a library does not use symbol versioning and changes incompatible without changing the soname, it's a bug.

Glibc seems to support only a buggy API such that multiple versions can't be used on the same machine as linked by file-name.

If you would understand a little bit about how starting ELF binaries works, it would be pretty clear that you can have only one ld.so, and thus only one version of glibc. Which itself is already incorrect, you can install multiple versions of glibc in parallel, but that's really not easy and you don't want that as normal user. And: 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 versions in parallel.

While some may think I have uniq problems, the intra-distro binaries are going to have more and more of these cases. It's not a workable situation.

Maybe Leap would be the right distro for you?

I can take programs in Win from 10-20 years ago and they still work on a current day win because the OS loads library updates by version. Unix did the same -- but move to linux, and vendors got lazy and stopped using the correct versions to link with. Why? And how can this be fixed?

??? Where did Linux stopped using the correct version to link with? All libraries with a public interface have a soname and many of them even symbol versioning. Else see above. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)

On 2021/02/16 23:30, Thorsten Kukuk wrote:

Seems you mix up Tumbleweed as rolling release distribution with openSUSE Leap/SLE as stable distribution. In the first case, you have always the newest stuff, in the later case, you have stable interfaces, with the drawback, this is old code.

Windows gets around it by having multiple so's -- installing the 'so' that each program compiled with.

Tumbleweed tries the best to provide all the new, shiny features in a stable way, Leap and SLE tries eveything to stay compatible without providing all the new features.

--- That answers my question about how many corporations are using TW. Though to be honest, I want to update my linux system about as often as I change Win OS's. Win 7 was out for about 12 years w/support. I was an early adopter and am still using it. But never was Win7 keeping me from using new programs (well until recently). How many progs from an opensuse release from 2008 would work on a system from today?

If you would understand a little bit about how starting ELF binaries works, it would be pretty clear that you can have only one ld.so, and thus only one version of glibc.

---- ld.so is supposed to be a loader. It works with other libraries just fine. It has intimate knowledge about glibc, but it doesn't need it from other libc (musl?) implementations.

Which itself is already incorrect, you can install multiple versions of glibc in parallel, but that's really not easy and you don't want that as normal user.

---- The user doesn't keep the multiple lib versions in Windows -- the OS does. It's not a matter of "can't" its a matter of the linux world being about 15 years behind in supporting new progs and old on the same OS. MS used to have 'dll/so' "hell", because they used to only be able to have 1 copy of a lib loaded in shared mem by the OS, but they fixed it so different progs can have different versioned libs -- why hasn't linux gone that route?

On 2021/02/17 09:34, Jan Engelhardt wrote:

On Wednesday 2021-02-17 16:19, L A Walsh wrote:

...

Windows gets around it by having multiple so's -- installing the 'so' that each program compiled with.

Which is a problematic approach too, because

(a) even functions that are unchanged between two versions now occupy extra disk space.

Back when disks were sized in MB, I was more concerned about that. However it doesn't seem to be an issue on today's disks.

(b) when a program loads two or more versions, possibly indirectly (and thus can't control it), the libraries compete on who gets to provide what symbol.

Why would 1 program load two or more versions? It only binds with 1.

And then things can crash because oh the library with the slightly different ABI won the dlopen competition.

--- The program binds with the lib it was built against in a similar way as binding with a static lib, but if that library is already installed, on a given machine, it can be shared with other programs that use the same version. Ultimately MS uses GUID's for describing uniq libraries. I've never heard of a program binding to 2 different libraries, but that seems like some sort of quantum binding where something can be 2 things at once. But once the program binds, it decays into 1 fixed state, no?

That said, the repositories ship multiple SOs when the dependency tree needs it.

Satisfying dependencies within 1 daily TW release is 1 thing, but I'm talking about satisfying dependencies for all programs the user has built or installed during the life of the OS's installation on the machine. I shouldn't have to wipe my machine's OS during it's lifetime unless there is a problem, but given that I build my own packages and rebuild my own versions of some from included sources, that means there are dependencies on my machine for some library versions that wouldn't be listed in a repository's manifest. I would expect that the libraries I build with aren't going to suddenly become unavailable for programs I've built myself. Not being able to build and install your own SW makes a personal computer a bit less useful, especially where open source is involved.

четвер, 18 лютого 2021 р. 00:40:06 EET L A Walsh написано:

On 2021/02/17 09:34, Jan Engelhardt wrote:

...

Which is a problematic approach too, because

(a) even functions that are unchanged between two versions now occupy extra

disk space.

--- Back when disks were sized in MB, I was more concerned about that. However it doesn't seem to be an issue on today's disks.

You should understand, that different files on disk also mean different code segments in memory. While code of one .so in different processes uses same segment shared between all processes. It's not just disk, but RAM overhead too. -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський

...

Though to be honest, I want to update my linux system about as often as I change Win OS's. Win 7 was out for about 12 years w/support. I was an early adopter and am still using it. But never was Win7 keeping me from using new programs (well until recently). How many progs from an opensuse release from 2008 would work on a system from today?

How much do you pay for openSUSE and how much did you pay for Windows?

Please, we should never use this argument. To say "openSUSE is free, so don't expect the quality of payed system" destroys all the hard work invested in it. With these attitude we can simply put on https://get.opensuse.org/ some big red warning "Don't use it, it is free and therefore it is bad". And I think, we don't want that.

On 2/17/21 8:30 PM, Axel Braun wrote:

Am Mittwoch, 17. Februar 2021, 20:10:05 CET schrieb Daniel Noga:

...

...

How much do you pay for openSUSE and how much did you pay for Windows?

Please, we should never use this argument. To say "openSUSE is free, so don't expect the quality of payed system" destroys all the hard work invested in it. With these attitude we can simply put on https://get.opensuse.org/ some big red warning "Don't use it, it is free and therefore it is bad". And I think, we don't want that.

To add my experience of the day, at a customer site: Windows needs a helpdesk, Tumbleweed just runs.....

If that was true, we wouldn't have a business model. No, even Linux doesn't just run. Adrian

On 17/02/2021 20.56, Jan Engelhardt wrote:

On Wednesday 2021-02-17 20:10, Daniel Noga wrote:

...

...

...

Though to be honest, I want to update my linux system about as often as I change Win OS's. Win 7 was out for about 12 years w/support. I was an early adopter and am still using it. But never was Win7 keeping me from using new programs (well until recently). How many progs from an opensuse release from 2008 would work on a system from today?

How much do you pay for openSUSE and how much did you pay for Windows?

Please, we should never use this argument. To say "openSUSE is free, so don't expect the quality of payed system" destroys all the hard work invested in it.

openSUSE is free AND please don't expect the (poor) quality of a paid system.

That's a good point. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On Wednesday 2021-02-17 21:38, John Paul Adrian Glaubitz wrote:

On 2/17/21 8:56 PM, Jan Engelhardt wrote:

...

...

Please, we should never use this argument. To say "openSUSE is free, so don't expect the quality of payed system" destroys all the hard work invested in it.

openSUSE is free AND please don't expect the (poor) quality of a paid system.

By this logic, SLE - which is based on openSUSE and vice versa - is poor quality then.

well, then ... of a CERTAIN paid system, usually the one that was mentioned in the discussion. Quality: Only available for one or two architectures. Does not even come with the basics like an office writer or spreadsheet. Value: It also isn't libre, which is hard to put a concrete value on, but it's valuable nevertheless. So Windows falls short both in quality and value-per-euro.

On 2/18/21 6:49 AM, Thorsten Kukuk wrote:

...

By this logic, SLE - which is based on openSUSE and vice versa - is poor quality then.

No, because you don't pay for SLE as product, but for support and maintenance.

Actually, you do as large amounts of open source code is developed by paid developers, for example for the Linux kernel [1]. The basement dwelling Unix neckbeard that is primarily driving the open development at no charge has been a myth for a very long time already. Most development in products like Firefox, the kernel, GCC, binutils, Go etc is done by paid developers. There is no free lunch. Adrian

[1] https://www.linuxfoundation.org/blog/the-top-10-developers-and-companies-con...

Am 18.02.21 um 07:42 schrieb John Paul Adrian Glaubitz:

On 2/18/21 6:49 AM, Thorsten Kukuk wrote:

...

No, because you don't pay for SLE as product, but for support and maintenance.

Actually, you do as large amounts of open source code is developed by paid developers, for example for the Linux kernel [1].

That's where most of the money ends up, but Thorsten is probably right that most SUSE customers have more the support and maintenance in mind when they pay you.

The basement dwelling Unix neckbeard that is primarily driving the open development at no charge has been a myth for a very long time already.

Let's be fair, it's a bit of both (if we include volunteer contributors at other building levels and without facial hair). Of course some projects have mostly corporate contributions, but there are also many (often smaller) projects that have mostly volunteer contributors.

Most development in products like Firefox, the kernel, GCC, binutils, Go etc is done by paid developers.

There is no free lunch.

Technically the lunch is free: all of these programs are available free of charge, there are no hidden costs and there is no other way you end up paying for it. It's not even like social media where you pay with your data. Software and other kinds of "IP" have near zero marginal cost. So somebody has to pay for it, but once its paid for, everybody can get it for free if the license allows it. There is virtually no cost to providing the software to more people, so the "no free lunch" theorem doesn't apply in my view. Which is not a bad thing: people in third world countries can also download and install openSUSE for free and none of us need to bothered by it (ignoring the support cost and just considering the software). Best regards, Aaron

On 2/19/21 8:19 AM, Johannes Meixner wrote:

...

That's where most of the money ends up, but Thorsten is probably right that most SUSE customers have more the support and maintenance in mind when they pay you.

All of them are right (otherwise things won't work for a longer time):

Customers pay SUSE for support and maintenance and SUSE's paid kernel developers provide that for the kernel and other SUSE people provide that for other components.

In particular customers with specific hardware in their data center and specific software requirements for their special environments that no free software volunteer would ever have at home can pay someone who can provide support and maintenance for their specific needs.

I'm pretty sure that paid SUSE developers work on support for new hardware and not just on the stuff that we are selling to enterprise customers. Takashi, for example, is the primary maintainer of the Linux sound stack and he is being paid for that work. In Debian, both the toolchain and the kernel maintainers are paid professionals. Many Debian developers work for companies like Canonical, Credativ or Collabora. But I wasn't so much focusing on SUSE or other distribution vendors only. A Linux distribution is the result of the work of thousands of developers with most of the work share being done by upstream projects and very often by developers. So why you don't have to pay for openSUSE itself, it's still very much the result of paid work which was cross-subsidized by customers buying hardware or support contracts. Try projects like OpenBSD as a counter-example which don't have large corporate backings and as a result, OpenBSD's hardware support is very limited as compared to Linux - something which you can't blame them for given the lack of corporate funding and manpower. Adrian

Hello, On 2021-02-19 09:13, John Paul Adrian Glaubitz wrote:

On 2/19/21 9:05 AM, John Paul Adrian Glaubitz wrote:

...

But I wasn't so much focusing on SUSE or other distribution vendors only. A Linux distribution is the result of the work of thousands of developers with most of the work share being done by upstream projects and very often by developers.

by paid* developers, I need coffee

paid coffee of course - paid by our customers - shudder - crazy world ;-) Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

On Fri, Feb 19, 2021 at 08:56:23AM +0100, John Paul Adrian Glaubitz wrote:

Volunteer contributors are negligible when it comes to larger changes at the codebase or regular contributions. Maintaining a kernel port or working on GCC is almost always a full time job.

Worth remembering that many volunteers' interest was sparked by their rights to accessible code and having their own itch to scratch, which has led many into aligned full time jobs. The first two-line commit might have taken moments to type, but was perhaps the outcome of weeks going down the rabbit-hole, trying to isolate an issue and fathom out how the blocks/sub-systems/projects interacted. Harnessing and directing some of that enthusiasm is perhaps the art of a successful distro or opensource project. Daniel

Am 19.02.21 um 08:56 schrieb John Paul Adrian Glaubitz:

Volunteer contributors are negligible when it comes to larger changes at the codebase or regular contributions. Maintaining a kernel port or working on GCC is almost always a full time job.

Perhaps we're just talking about different things here. I'm well aware where most of the code in the kernel, GCC and LLVM comes from. But Tumbleweed has ~15,000 packages, and the overall ecosystem does have a lot of volunteer contributions. As important as the kernel, compiler and browser are, a Linux distribution is much more than that. Best regards, Aaron

On 2021/02/17 09:53, John Paul Adrian Glaubitz wrote:

It's rather obvious that a rolling release distribution isn't something that corporations should use. You don't want your database server to become offline because the daemon won't restart after an update because the database format changed from one major version to another.

--- But you might want the new version of the latest CMS to go with your website. If you wait for 2-3 years till it comes out in leap, you've missed most of your window. Similarly with any product, one might need a new feature from a newer product and might even be able to _test_ the product to see if it meets one's needs. That does not mean one wants an unstable system by replacing all packages every day as could be the case w/TW.

...

Though to be honest, I want to update my linux system about as often as I change Win OS's. Win 7 was out for about 12 years w/support. I was an early adopter and am still using it. But never was Win7 keeping me from using new programs (well until recently). How many progs from an opensuse release from 2008 would work on a system from today?

How much do you pay for openSUSE and how much did you pay for Windows?

0 and 0. Is there a point? You might claim I paid some fee for Win, but that's a tax on the HW platform I don't have much choice about. Given that its the same cost for openSUSE as Windows. If oSS published a broken, gimped or "nerf"ed package, it _should_ be possible to build it myself and I could, (and _have_) sent back the fixes. With Windows I wouldn't be able to do that, though also, w/Windows, I'd be less likely to know the state of the package. So what's your point?

...

...

Which itself is already incorrect, you can install multiple versions of glibc in parallel, but that's really not easy and you don't want that as normal user.

---- The user doesn't keep the multiple lib versions in Windows -- the OS does. It's not a matter of "can't" its a matter of the linux world being about 15 years behind in supporting new progs and old on the same OS.

Multiple copies of the same library is a security problem which is why Linux distributions avoid that.

Good thing the MS platform never has security problems. Oh wait -- they do, but don't seem to have the same security problem(s) Linux has. Are you implying Linux can't handle security problems as easily as MS can? Perhaps Linux should copy MS's methodology for that -- i.e. providing multiple versions.

...

MS used to have 'dll/so' "hell", because they used to only be able to have 1 copy of a lib loaded in shared mem by the OS, but they fixed it so different progs can have different versioned libs -- why hasn't linux gone that route?

Shipping every program with every shared library it needs isn't a solution,

That would be an onerous burden if it was what anyone did. Fortunately that's not what MS or developers on that platform do. Presenting a straw-man problem as the counterpoint to the broken linux way, is pointless.

it's a hack. I would argue that there isn't really the perfect solution to the shared library problem

So in addition to not knowing how MS solves this issue you also say it can't be solved and 'punt' with a poorly integrated solution that dwarfs the disk cost of shipping an update.exe along with the app-install.exe that only loads the minimal set of libs needed and that are not already on the users machine.

although I think Flatpak does the balance between easy installation and handling of security updates and shared library deduplication pretty well.

"a sandbox environment in which users can run application software in isolation from the rest of the system" - wikipedia -- isolated from the rest of the OS doesn't mean "integrated" nor dedupped. Flatpak's store shared resources in a "com.company.App/i386/version" os-tree. So for TW, that'd be a different lib for each day TW is released. i.e. zero deduplication. So far, I'm not seeing solutions that allow me to rebuild suse apps from source rpm's.

On Fri, Feb 19, 2021 at 06:08:37PM -0800, L A Walsh wrote:

On 2021/02/17 09:53, John Paul Adrian Glaubitz wrote:

...

...

...

Which itself is already incorrect, you can install multiple versions of glibc in parallel, but that's really not easy and you don't want that as normal user.

---

The user doesn't keep the multiple lib versions in Windows -- the OS does. It's not a matter of "can't" its a matter of the linux world being about 15 years behind in supporting new progs and old on the same OS.

Multiple copies of the same library is a security problem which is why Linux distributions avoid that.

---

Good thing the MS platform never has security problems. Oh wait -- they do, but don't seem to have the same security problem(s) Linux has. Are you implying Linux can't handle security problems as easily as MS can? Perhaps Linux should copy MS's methodology for that -- i.e. providing multiple versions.

That multiplies the work for them, and at some point they decide to stop supporting soe of the old libraries and they stay forever broken yet your abandonware software will keep using it forever.

...

...

MS used to have 'dll/so' "hell", because they used to only be able to have 1 copy of a lib loaded in shared mem by the OS, but they fixed it so different progs can have different versioned libs -- why hasn't linux gone that route?

Shipping every program with every shared library it needs isn't a solution,

---

That would be an onerous burden if it was what anyone did. Fortunately that's not what MS or developers on that platform do. Presenting a straw-man problem as the counterpoint to the broken linux way, is pointless.

Yes, MS developers don't their code is part of the platform and they do maintain the parts of the platform that are still under supporte. But application developers do. That's actually what MS suggests them to do.

...

it's a hack. I would argue that there isn't really the perfect solution to the shared library problem

---

So in addition to not knowing how MS solves this issue you also say it can't be solved and 'punt' with a poorly integrated solution that dwarfs the disk cost of shipping an update.exe along with the app-install.exe that only loads the minimal set of libs needed and that are not already on the users machine.

Well, they don't solve it. They update the MS platform and punt updating any other libraries to the software vendors. So when there is a bug in a popular library every vendor that uses it must release update of ther software with the bundled library. If the software in question is some abandonware that is no longer developed or some freeware side project that gets little attention you are out of luck. It will stay broken for a long tie or even forever.

...

although I think Flatpak does the balance between easy installation and handling of security updates and shared library deduplication pretty well.

---

"a sandbox environment in which users can run application software in isolation from the rest of the system" - wikipedia -- isolated from the rest of the OS doesn't mean "integrated" nor dedupped. Flatpak's store shared resources in a "com.company.App/i386/version" os-tree.

So for TW, that'd be a different lib for each day TW is released. i.e. zero deduplication.

You don't use flatpak to install TW. You use flatpak to install applications that are not available on a stable distribution (in the version you want). Of course, doing that has some disadvantages. At the very least flatpak aims to do some deduplication of installed libraries as opposed to full vendoring other distribution-neutral packaging does. Best regards Michal

On 2/18/21 1:49 AM, L A Walsh wrote:

...

Seems you mix up Tumbleweed as rolling release distribution with openSUSE Leap/SLE as stable distribution. In the first case, you have always the newest stuff, in the later case, you have stable interfaces, with the drawback, this is old code.   Windows gets around it by having multiple so's -- installing the 'so'

On 2021/02/16 23:30, Thorsten Kukuk wrote: that each program compiled with.

...

Tumbleweed tries the best to provide all the new, shiny features in a stable way, Leap and SLE tries eveything to stay compatible without providing all the new features.  

---

   That answers my question about how many corporations are using TW.

   Though to be honest, I want to update my linux system about as often as I change Win OS's.  Win 7 was out for about 12 years w/support.  I was an early adopter and am still using it.  But never was Win7 keeping me from using new programs (well until recently).  How many progs from an opensuse release from 2008 would work on a system from today?

Well the tarball for setserial hasn't changed in atleast 14 years, according to the changelog it hasn't changed version since 2000, the only changes in the last 10 years were disabling init scripts and moving stuff into /usr so atleast some :-) -- 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

On 19/02/2021 15.00, Dominique Leuenberger / DimStar wrote:

On Wed, 2021-02-17 at 07:19 -0800, L A Walsh wrote:

...

On 2021/02/16 23:30, Thorsten Kukuk wrote:

...

Seems you mix up Tumbleweed as rolling release distribution with openSUSE Leap/SLE as stable distribution. In the first case, you have always the newest stuff, in the later case, you have stable interfaces, with the drawback, this is old code.   

Windows gets around it by having multiple so's -- installing the 'so' that each program compiled with.

...

Tumbleweed tries the best to provide all the new, shiny features in a stable way, Leap and SLE tries eveything to stay compatible without providing all the new features.   

---     That answers my question about how many corporations are using TW.

    Though to be honest, I want to update my linux system about as often as I change Win OS's. Win 7 was out for about 12 years w/support. I was an early adopter and am still using it. But never was Win7 keeping me from using new programs (well until recently). How many progs from an opensuse release from 2008 would work on a system from today?

Just tested:

...

rpm -ihv http://ftp4.gwdg.de/pub/opensuse/discontinued/distribution/10.2/repo/oss/sus...

This comes from openSUSE 10.2 - which was released in 2006; so 15 years ago. The package installs just fine - and runs.

So - case proven? can we move on now?

L A has a complicated problem you may not have been following. I don't remember all of it. A TW machine had some hardware problem and could not be updated for some months. The compression format of rpms changed meanwhile. The rpm code in the machine can not cope with the new format and the machine can not be updated. L A has been trying to build rpm program or libraries that can be installed on that system and tha can cope with that new format, but failed. There is a bugzilla about it. Part of the problem is people telling to use OBS and L A refusing for privacy or enterprise reasons, and rebuilding the rpm from published rpm source code seems to be impossible, unless done at the OBS, which is external to L A. I may of course have gaps in my understanding :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 19/02/2021 23.14, Axel Braun wrote:

Am 19. Februar 2021 22:43:22 MEZ schrieb "Carlos E.R." :

...

On 19/02/2021 15.00, Dominique Leuenberger / DimStar wrote:

...

On Wed, 2021-02-17 at 07:19 -0800, L A Walsh wrote:

...

L A has been trying to build rpm program or libraries that can be installed on that system and tha can cope with that new format, but failed. There is a bugzilla about it.

Part of the problem is people telling to use OBS and L A refusing for privacy or enterprise reasons, and rebuilding the rpm from published rpm source code seems to be impossible, unless done at the OBS, which is external to L A.

One can always build locally against OBS repos.

Arguably much more complex that rpmbuild command :-?

...

I may of course have gaps in my understanding :-)

Me as well, I guess

-- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 20/02/2021 10.55, Simon Lees wrote:

On 2/20/21 8:52 AM, Carlos E.R. wrote:

...

On 19/02/2021 23.14, Axel Braun wrote:

...

Am 19. Februar 2021 22:43:22 MEZ schrieb "Carlos E.R." :

...

On 19/02/2021 15.00, Dominique Leuenberger / DimStar wrote:

...

On Wed, 2021-02-17 at 07:19 -0800, L A Walsh wrote:

...

L A has been trying to build rpm program or libraries that can be installed on that system and tha can cope with that new format, but failed. There is a bugzilla about it.

Part of the problem is people telling to use OBS and L A refusing for privacy or enterprise reasons, and rebuilding the rpm from published rpm source code seems to be impossible, unless done at the OBS, which is external to L A.

One can always build locally against OBS repos.

Arguably much more complex that rpmbuild command :-?

More complex in the backend, but for openSUSE packages far simpler in terms of the effort that a user needs to go to in order to do it.

Certainly. OBS is easier on the maintainer, no doubt. After a learning curve. But not for someone doing spot builds, for whatever reasons - say, machines isolated from internet for privacy or security. It is just an opinion, a layman opinion perhaps, but I think the source rpms should be enough to re-build any package, they should work. Otherwise, I have my doubts we are "providing the source code" as per the free code licenses. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

Am Samstag, 20. Februar 2021, 00:23:57 CET schrieb Jan Engelhardt:

On Friday 2021-02-19 23:14, Axel Braun wrote:

...

...

Part of the problem is people telling to use OBS and L A refusing for privacy or enterprise reasons, and rebuilding the rpm from published rpm source code seems to be impossible, unless done at the OBS, which is external to L A.> One can always build locally against OBS repos.

`osc build` would still contact the scheduler to have it generate the dependency list, and it would contact one or more servers to download the build dependencies, which would be forbidden in the hermit kingdom of LA.

Sure. But if you want just the result to be private it works fine. So once you have all dependencies you can use -o to build. SOMEHOW one has to determine all dependencies, independent what if rpmbuild or osc build is used, and needs to get this on the disk. @Carlos - I havent used rpmbuild since I use osc. Cheers Axel

On 20/02/2021 10.24, Axel Braun wrote:

Am Samstag, 20. Februar 2021, 00:23:57 CET schrieb Jan Engelhardt:

...

On Friday 2021-02-19 23:14, Axel Braun wrote:

...

...

Part of the problem is people telling to use OBS and L A refusing for privacy or enterprise reasons, and rebuilding the rpm from published rpm source code seems to be impossible, unless done at the OBS, which is external to L A.> One can always build locally against OBS repos.

`osc build` would still contact the scheduler to have it generate the dependency list, and it would contact one or more servers to download the build dependencies, which would be forbidden in the hermit kingdom of LA.

Sure. But if you want just the result to be private it works fine. So once you have all dependencies you can use -o to build. SOMEHOW one has to determine all dependencies, independent what if rpmbuild or osc build is used, and needs to get this on the disk.

@Carlos - I havent used rpmbuild since I use osc.

And I have never used osc because it is way to difficult to learn. Yes, I tried. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

Am Sonntag, 21. Februar 2021, 21:43:20 CET schrieb L A Walsh:

On 2021/02/19 14:14, Axel Braun wrote:

...

One can always build locally against OBS repos.

---- One can always have a risc-chip virtual machine that builds your repos on your local machine, but that doesn't mean the resulting binary is installable on your local machine.

As OBS sets up a clean build environment you can compile against targets that do not match your setup

...

...

I may of course have gaps in my understanding :-)

Me as well, I guess

--- Yeah, your build target also has to be installable on your local machine. That's a primary reason for building on my local machine. The resulting rpm will use the libs on my machine at build time, and can be installed and work after they are built.

Using a foreign or virtual environment won't let you build, necessarily, for installation on your local machine.

I feel here's the gap: Depending on how 'individual' your system is your rpm installs on your machine, but on no other. Having a clean and reproduceable build environment is a *big* advantage in OBS.... Cheers Axel

On 2/22/21 1:47 PM, L.A. Walsh wrote:

On 2021/02/21 13:41, Axel Braun wrote:

...

I feel here's the gap: Depending on how 'individual' your system is your rpm installs on your machine, but on no other. Having a clean and reproduceable build environment is a *big* advantage in OBS....  

---    If someone has a pre-4.15 rpm, then they can't upgrade to suse's current packages.  They also cannot build or install an rpm>=4.15, so they can't get to the point of being able to use packages built on OBS.

This is simply not true 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 if you don't have rpm 4.14 or later on your machine its no longer in a state we support and you really only have two options, 1. use the upgrade function on the installation media, 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. 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. 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... -- 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

On 2021/03/09 06:26, Bernhard M. Wiedemann wrote:

On 22/02/2021 04.17, L.A. Walsh wrote:

...

But that misses the point. The starting point in all of this was to be able to install current rpm's on my system as I've been able to do for the past 15 years.

What keeps you from updating your Tumbleweed to https://opensuse.zq1.de/history/20200801/tumbleweed/repo/oss/ that has every rpm .xz compressed(as has been the case for a long time)?

==== Other than this is the first I've heard of it, I'm not sure. When did opensuse switch to the new rpm-compression? I should see if any rpms from that site are readable, though I just managed to install rpm 4.14.1 from leap (though am not sure how much that helps anything). As for what keeps me from updating ... I dunno what would work and what wouldn't until I try. So asking me what is keeping me from doing anything with something I didn't know anything about before you mentioned it -- hard to say really! ;-)

On 10/03/2021 03.23, Neal Gompa wrote:

On Tue, Mar 9, 2021 at 9:04 PM L A Walsh wrote:

...

On 2021/03/09 06:26, Bernhard M. Wiedemann wrote:

...

On 22/02/2021 04.17, L.A. Walsh wrote:

...

But that misses the point. The starting point in all of this was to be able to install current rpm's on my system as I've been able to do for the past 15 years.

What keeps you from updating your Tumbleweed to https://opensuse.zq1.de/history/20200801/tumbleweed/repo/oss/ that has every rpm .xz compressed(as has been the case for a long time)?

==== Other than this is the first I've heard of it, I'm not sure. When did opensuse switch to the new rpm-compression? I should see if any rpms from that site are readable, though I just managed to install rpm 4.14.1 from leap (though am not sure how much that helps anything).

As for what keeps me from updating ... I dunno what would work and what wouldn't until I try. So asking me what is keeping me from doing anything with something I didn't know anything about before you mentioned it -- hard to say really! ;-)

First: You should be updating your Tumbleweed system continuously, not letting it lag like this and letting it break.

You know, because it has been told more than once, that the system in question had hardware trouble and could not be updated for some months. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 10/03/2021 03.04, L A Walsh wrote:

On 2021/03/09 06:26, Bernhard M. Wiedemann wrote:

...

What keeps you from updating your Tumbleweed to https://opensuse.zq1.de/history/20200801/tumbleweed/repo/oss/ that has every rpm .xz compressed(as has been the case for a long time)? ====     Other than this is the first I've heard of it, I'm not sure.

I had written about it on https://lizards.opensuse.org/2019/04/03/experimental-opensuse-mirror-via-ipf... and mentioned a few times on reddit and factory ML, but I dont have the time to do big advertising and it more of a side-project that I keep working as good as I can with 6TB of online disk space.

When did opensuse switch to the new rpm-compression?

around 2020-08-26, so it should work.

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:

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

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

On Mon, Feb 22, 2021 at 10:20:09AM +1030, Simon Lees wrote:

On 2/22/21 7:13 AM, L A Walsh wrote:

...

On 2021/02/19 14:14, Axel Braun wrote:

...

One can always build locally against OBS repos.  

---    Yeah, your build target also has to be installable on your local machine.  That's a primary reason for building on my local machine.  The resulting rpm will use the libs on my machine at build time, and can be installed and work after they are built.

At this point it sounds more like you are trying to build a derivative distribution "Based on openSUSE" just for one machine.

...

Using a foreign or virtual environment won't let you build, necessarily, for installation on your local machine.

One feature of open build service that people building derivative distros use is that packages will use other packages in the same project / repo for builds. So if all the custom packages you are using on your machine are in the same project then it will use them for builds. This gives you other advantages as well in that if you update one of the libraries it will automatically rebuild all the packages that depend on it.

There is no such project. The packages are some obsolete TW snapshot. And building on Leap may or may not work - I think the new rpm spec file uses features of the new rpm so it is not buildable with old rpm. I suppose that at some point in the history of the rpm package it contained the new sources and was buildable with old rpm but you need to find that, rebuild with old rpm, and then you can install the current one. Not exactly nice experience. And it's quite possible that such sources were only present in some bootstrap project and locating them in OBS is pretty much impossible. Thanks Michal

On Tue, Feb 23, 2021 at 08:44:34PM +1030, Simon Lees wrote:

On 2/23/21 8:20 PM, Michal Suchánek wrote:

...

On Mon, Feb 22, 2021 at 10:20:09AM +1030, Simon Lees wrote:

...

On 2/22/21 7:13 AM, L A Walsh wrote:

...

On 2021/02/19 14:14, Axel Braun wrote:

...

One can always build locally against OBS repos.  

---    Yeah, your build target also has to be installable on your local machine.  That's a primary reason for building on my local machine.  The resulting rpm will use the libs on my machine at build time, and can be installed and work after they are built.

At this point it sounds more like you are trying to build a derivative distribution "Based on openSUSE" just for one machine.

...

Using a foreign or virtual environment won't let you build, necessarily, for installation on your local machine.

One feature of open build service that people building derivative distros use is that packages will use other packages in the same project / repo for builds. So if all the custom packages you are using on your machine are in the same project then it will use them for builds. This gives you other advantages as well in that if you update one of the libraries it will automatically rebuild all the packages that depend on it.

There is no such project. The packages are some obsolete TW snapshot. And building on Leap may or may not work - I think the new rpm spec file uses features of the new rpm so it is not buildable with old rpm. I suppose that at some point in the history of the rpm package it contained the new sources and was buildable with old rpm but you need to find that, rebuild with old rpm, and then you can install the current one. Not exactly nice experience. And it's quite possible that such sources were only present in some bootstrap project and locating them in OBS is pretty much impossible.

My reply here was to

...

...

...

Using a foreign or virtual environment won't let you build, necessarily, for installation on your local machine.

It is clear that at this point the only real solution is upgrading rpm to the latest version using one of our provided packages (possibly via first installing an intermediate rpm version) then optionally using that package to rebuild itself and going from there. But at this point i'm really not sure why we are still discussing it on this list as what is being done here is far from any form of supported openSUSE system.

Also from your analysis in your other mail it is clear that the rpm package is not months old but much older. According to the report the user did not upgrade for a few months but ended up with rpm 4.11 which is very old - 4.12 was introduced in 2014. So this is clearly some problem with the system - using package lock, having old software installed that prevents the rpm upgrade, or whatever. If you break it you get to keep the pieces. Can't do much about that. Thanks Michal

On Tue, 2021-02-23 at 10:50 +0100, Michal Suchánek wrote:

There is no such project. The packages are some obsolete TW snapshot. And building on Leap may or may not work - I think the new rpm spec file uses features of the new rpm so it is not buildable with old rpm. I suppose that at some point in the history of the rpm package it contained the new sources and was buildable with old rpm but you need to find that, rebuild with old rpm, and then you can install the current one. Not exactly nice experience. And it's quite possible that such sources were only present in some bootstrap project and locating them in OBS is pretty much impossible

There is so much speculation, it hurts. The only thing that really chaged was the payload compression format used in Tumblewed - we switched to zstd in Tumbleweed somewhen in 2020 (Snapshot 20200825) See also http://dominique.leuenberger.net/blog/2020/08/opensuse-tumbleweed-review-of-... We had supported decompressing zstd payload for roughly a year beforehand. Leap 15.2's rpm version supports decompressing the zstd payload (and Leap's RPM package is not zstd compressed) In case you need/want to dup from something older, use the DVD/NET iso and do an offline upgrade (i.e. not on the running system). Cheers, Dominique

On 28/02/2021 22.15, L A Walsh wrote:

On 2021/02/23 01:50, Michal Such������������������������ wrote:

...

On Mon, Feb 22, 2021 at 10:20:09AM +1030, Simon Lees wrote:

...

One feature of open build service that people building derivative distros use is that packages will use other packages in the same project / repo for builds. So if all the custom packages you are using on your machine are in the same project then it will use them for builds. This gives you other advantages as well in that if you update one of the libraries it will automatically rebuild all the packages that depend on it.

There is no such project. The packages are some obsolete TW snapshot.

---

   ^^^ Yep!  Disk crash = I lost the TW snapshots things were built against, as it was on my "downloaded from the Internet" disk which wasn't backed up, as I thought I could always download it again and go from there.

But why do you have rpm 4.11? It is older than year 2014. Read Michal Suchánek post about that. Archived-At: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 20/02/2021 15.14, Rodney Baker wrote:

On Saturday, 20 February 2021 8:13:22 ACDT Carlos E.R. wrote:

...

[...]

L A has a complicated problem you may not have been following. I don't remember all of it.

A TW machine had some hardware problem and could not be updated for some months. The compression format of rpms changed meanwhile. The rpm code in the machine can not cope with the new format and the machine can not be updated.

L A has been trying to build rpm program or libraries that can be installed on that system and tha can cope with that new format, but failed. There is a bugzilla about it.

Part of the problem is people telling to use OBS and L A refusing for privacy or enterprise reasons, and rebuilding the rpm from published rpm source code seems to be impossible, unless done at the OBS, which is external to L A.

I may of course have gaps in my understanding :-)

So nobody suggested downloading or creating a current Live DVD, booting from that (to ensure that the rpm version and libraries are current), then chrooting the problem system and updating that way (at lease for rpm and it dependencies)? Or is that too dangerous to try?

I think I suggested this or something similar. I don't remember. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

середа, 17 лютого 2021 р. 00:08:01 EET L A Walsh написано:

This is another example of a snapshot that will make package upgrades impossible w/o a full rebuild -- for a similar reason rpm 4.15 can't be built by rpm 4.14 or before. rpm 4.11 ships with rpmlibs-v3, while rpm4.15 ships rpmlibs-v9. The libs jumped 6 versions while rpm went up 0.14.

The windows of what binaries work with what date of TW is too small.

How is this connected to binaries? I have quite old (about 5 years) proprietary program which was built on/for CentOS 7 (not new OS either) and it works fine on TW (have checked before transiting our server to Leap).

While some may think I have uniq problems, the intra-distro binaries are going to have more and more of these cases. It's not a workable situation.

I can take programs in Win from 10-20 years ago and they still work on a current day win because the OS loads library updates by version. Unix did the same -- but move to linux, and vendors got lazy and stopped using the correct versions to link with. Why? And how can this be fixed?

As for Windows, same for Linux, if program supposed to work on wide variety of systems, you provide it with all libraries it needs with minimal dependency on system libraries. Windows have no standard way of dependencies so every app HAVE TO drag all stuff with it. WinSxS is a way to keep all that stuff in a non-controversial form (and reduce duplication in theory, though in practice it still keeps a bunch of different versions of the same library because they are slightly different), it doesn't provide dependencies for you. In Linux you could do the same, but most proprietary packagers prefer either static builds or bundle everything, because implementing this stuff in proper way needs a normal repository with at least RPM/DEB structure. For some time there is a FlatPak to solve this problem, which has its own packaging format, repositories and dependencies. While I'm not a fan of it (as it has disk/RAM overhead) but it is a solution to not duplicate efforts for developers. As for open-source packages, keeping binary compatibility is not needed, it's simpler to rebuild packages against new library and get rid of code duplication. -- Kind regards, Mykola Krachkovsky -- Найкращі побажання, Микола Крачковський