Dear Tumbleweed users,
At the moment, Tumbleweed snapshot 20210212 is being synced out to the mirrors; the public announcement of the snapshot being available will (estimated) be at around 12pm CET.
I want to inform you upfront of a few specialties:
* The snapshot is going to be large, in the number of packages to 'update' (mostly rebuild counters) and thus also megabytes. * The snapshot is the first to be based on glibc 2.33 https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html
While testing this snapshot, a few things were broken (which delayed publishing a bit). There are, however, still two issues known which you should be aware of:
* NIS integrated system administrators might want to check out https://bugzilla.opensuse.org/show_bug.cgi?id=1182247 - the nss_compat module does not load additional modules, which means you might have to adjust the nsswitch.conf to make 'nis' an explicit setting. * Especially on 32bit systems we had seen a bunch of sandboxing features not behaving as expected. This currently (still) affects libqt5-qtwebengine. An additional fix is currently being published in parallel into the update channel (http://download.opensuse.org/update/tumbleweed/). In case you see rendering issues (kmail for example) make sure to have this update included.
The other fixes (OpenSSH, chromium) which we had seen in prior testings are already included in snapshot 20210212 and should not be of concern.
As usual, if you see new bugs appearing, please verify if somebody else already filed them in bugzilla.opensuse.org and, if not already present, file the bugs yourself.
Cheers, Dominique
Hi,
On Tue, Feb 16, Dominique Leuenberger / DimStar wrote:
- NIS integrated system administrators might want to check out
https://bugzilla.opensuse.org/show_bug.cgi?id=1182247 - the nss_compat module does not load additional modules, which means you might have to adjust the nsswitch.conf to make 'nis' an explicit setting.
Since this sounds like this is a problem only with NIS: this is a generic problem with nss_compat. So if you use LDAP or anything else with nss_compat, you will face the exact same problems.
And don't forget, that with the above "workaround", the "+" and "-" directives in /etc/passwd and /etc/group don't work.
Thorsten
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.
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.
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.
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?
On 2/16/21 11:08 PM, L A Walsh wrote:
Is suse supporting this model for enterprise customers? I can't believe they would tolerate it.
No, SLE has different upgrade mechanisms which provide defined upgrade paths. A rolling release distribution naturally doesn't follow that model and breaking changes are the very nature of a rolling release distribution.
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 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.
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.
Adrian
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 2/17/21 9:35 PM, L A Walsh wrote:
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 andprobably 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.
No, I'm not. Your understanding on the inner workings of Windows is rather superficial. I recommend you talk to the WINE developers as they will explain you that the reality is much more complex.
Try running a 16-bit application on a 64-bit Windows, for example. That won't work because VM86 mode is not available in long mode on x86_64 systems.
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'twork 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.
Which is essentially a virtual machine hence you're proving my point.
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 linux30 years ago this month and V1.0 didn't come out until 1994. I'm pretty sure it wasn't binary compatible.
Version 1.0 wasn't the first release of Linux but the first one where X11 worked properly (if I remember correctly).
See: https://en.wikipedia.org/wiki/Linux#Creation
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.
Why would you want to run a recent version of glibc on an old kernel, that makes no sense. You want to run old application software in a recent Linux environment and that will work perfectly fine because both the Linux kernel and the glibc still provide the necessary ABIs for software that old.
But then you are saying what I said in saying that users need toprovide 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.
Microsoft doesn't provide libraries either. In fact, having been a professional developer for Windows, macOS and Linux desktop applications, I can tell you that collecting and distributing shared libraries has always been the most hassle with Windows. It's much easier with Linux and macOS which have actually decent mechanisms with their package managers for that - albeit on macOS you have to install Brew or Macports first, but that's actually very easy.
Microsoft has just recently started providing a package manager for Windows and my last information was that it was still in early beta.
That said -- most linux progs don't link to shareable objectlibraries 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?
Because you want to make sure that all packages use the latest symbol versions.
If you're not comfortable with that, then I'd actually recommend using Leap or similar distributions with a longer release cycle.
I mean, you're basically complaining that a two-seated race car is impractical for going on family. openSUSE Tumbleweed is a rolling-release distribution, it is unstable by _definition_ (not in the sense that it crashes but that the software changes often).
Adrian
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
On Wed, Feb 17, 2021, at 08:30, Thorsten Kukuk wrote:
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?
Also if you need applications with different libraries than your current system you can use: - flatpaks - snaps - AppImages - a VM - toolbox
/Syds
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 Wednesday 2021-02-17 16:19, 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.
Which is a problematic approach too, because
(a) even functions that are unchanged between two versions now occupy extra disk space. (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.
And then things can crash because oh the library with the slightly different ABI won the dlopen competition.
That said, the repositories ship multiple SOs when the dependency tree needs it.
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.
Am 17.02.21 um 23:40 schrieb L A Walsh:
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 might not be concerned, but others perhaps don't want to carry every version of every library that ever existed.
Why would 1 program load two or more versions?
Transitive dependencies: libraries might load other libraries. That's a real thing, especially in packaging ecosystems where version-locked dependencies are the norm.
In Tumbleweed I sometimes had issues with KDevelop after major LLVM updates: the application itself uses libLLVM.so via libclang-cpp.so, but since it's a GUI program it also uses Mesa, which will (depending on your graphics card) also sometimes load libLLVM.so. Now if KDevelop and Mesa were compiled against different versions of LLVM you'd observe strange behavior right up to crashes.
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.
Which sadly is unlikely to happen if everybody just happens to link with the library that was current when they started writing their code.
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?
In all fairness, Windows has a much smaller set of "system" libraries. Many libraries are just vendored into applications, so every application has their private version of them. The application itself and the libraries it uses are then typically build against a consistent snapshot of the system libraries, so you probably don't need to mix versions.
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.
If you're installing something, you're hopefully doing so via zypper and then you'll get updates. (As long as the package is maintained.)
If you build something yourself, then indeed required libraries could one day disappear from the repositories. But not necessarily from your system. The soname of a library is often part of the package name and so multiple versions can happily coexist, and you should be able to keep them as long as you need.
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.
Perhaps you should use "osc build" for your own packages? That builds in a chroot making sure you're only using the packages you have declared.
Best regards, Aaron
четвер, 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.
On 2/17/21 4:19 PM, 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.
That's not really a solution though. Having ten copies of libpng on your harddisk means you will have to update ten copies of libpng when there is a vulnerability.
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.
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.
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?
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.
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, it's a hack. I would argue that there isn't really the perfect solution to the shared library problem, although I think Flatpak does the balance between easy installation and handling of security updates and shared library deduplication pretty well.
Adrian
Though to be honest, I want to update my linux system about as oftenas 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.
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.....
My 2c Axel
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 Wednesday 2021-02-17 20:10, Daniel Noga wrote:
Though to be honest, I want to update my linux system about as oftenas 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.
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 oftenas 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.
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.
Adrian
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 Wed, Feb 17, 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.
No, because you don't pay for SLE as product, but for support and maintenance.
Thorsten
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
Hello,
On 2021-02-19 00:49, Aaron Puchert wrote:
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
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.
Kind Regards Johannes Meixner
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
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
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
On 2/19/21 12:49 AM, Aaron Puchert wrote:
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.
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.
For example, the m68k and vax backends in GCC still had to be converted to MODE_CC and there were no volunteers to work on that issue. So to get these tasks done, I actually had to start a Bountysource campaign for each:
https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mod... https://www.bountysource.com/issues/91495157-vax-convert-the-backend-to-mode...
If you look at commit diffs each, you see that those aren't changes that a hobbyist makes over a weekend:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6cebc6cbbb801183090dbb2752... https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e552abe2ba27ccec0d7c0d050b...
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.
That was not my point. I was not talking about the software itself. I was talking about the development work. Professional developer time is expensive and virtually all big corperations like Intel, AMD or IBM have paid developers working on Linux hardware support.
Some younger Linux may not remember this, but there used to be times where it couldn't be taken for granted that you could buy a rather recent piece of hardware and Linux would work on it out of the box. Hardware support was much much worse and the fact that it works out of the box these days is because Linux has become so mainstream, that hardware vendors write the drivers themselves.
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.
That's not the point at all. The point is that someone actually pays for the development of the software. The difference is simply whether the end result is shared with non-paying customers or not. That doesn't change the fact that Linux is mostly developed by paid developers.
Try getting a new backend into LLVM, Go or the kernel. It's _almost_ impossible if you don't have a corporate backing. I know this from first hand because I'm currently working on getting an M68k backend upstreamed into LLVM. Getting a new backend into Go is basically impossible unless you're a big corporation.
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).
People often just buy pirated versions of Windows in these countries. If you go to China or Vietnam, you can buy knock-off versions of Windows for a fraction of the original price in regular shops. In Shenzhen in particular, you can basically buy cheap knock-offs of everything.
Adrian
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
On Fri, Feb 19, 2021 at 10:19:14AM +0000, Daniel Morris wrote:
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 2/17/21 8:10 PM, Daniel Noga wrote:
Though to be honest, I want to update my linux system about as oftenas 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.
I think you missed one part in his argument where he mentioned the 12 years of support for a single release and this is certainly something that you don't get for free in openSUSE or any other Linux distribution.
The fact that Microsoft provided 12 years of free software updates for Windows 7 is rather unusual. If you want to get long-term support over such a long period for a Linux distribution, you usually have to pay for it because the maintainers to provide these updates are being paid for that - I'm one of them.
Linux is free software as in free speech, not as in free beer.
Adrian
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 2/20/21 12:38 PM, L A Walsh wrote:
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.
Ideally we would get Leap to the point where its easy to do just this, but with the CMS or whatever the latest core component you need you install by yourself, either manually or maybe from a package you fork / create on open build service. People are working on the ability to ship multiple python / php versions with limited effort on Leap. Then you get the best of both worlds, a stable base platform for 3-4 years but with security updates and whatever latest production software you need, this is what a number of SUSE Customers do.
Personally I created https://build.opensuse.org/project/show/home:simotek:base (needs a cleanup) if I need the latest version of something for Leap (or SLE) I just branch it into there and its almost 0 effort
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.
Yep, most people just use obs to do this because generally its quicker and easier.
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/23/21 10:32 AM, Michal Suchánek wrote:
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.
Well, it's also not like Windows hasn't been an attractive target for botnet creators for years [1]. So, I'm pretty confident that if you analyzed your average Joe Windows system, you would certainly find a number of unresolved CVEs in many of the installed shared libraries and applications.
On Windows, there is simply no authoritative source for shared libraries that makes sure these are always kept up-to-date and hence on a secure level.
Another very popular gateway for intruders has always been the Flash Player on Windows and it's been used even by authorities to gain access to the computers of a target person.
Adrian
[1] https://en.wikipedia.org/wiki/Botnet#Historical_list_of_botnets
On 2/18/21 1:49 AM, 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?
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 :-)
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?
Cheers, Dominique
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 :-)
Am 19. Februar 2021 22:43:22 MEZ schrieb "Carlos E.R." robin.listas@gmx.es:
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.
I may of course have gaps in my understanding :-)
Me as well, I guess
Schöne Grüße Axel
On 19/02/2021 23.14, Axel Braun wrote:
Am 19. Februar 2021 22:43:22 MEZ schrieb "Carlos E.R." robin.listas@gmx.es:
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
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." robin.listas@gmx.es:
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.
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." robin.listas@gmx.es:
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.
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.
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.21 10:24, Axel Braun wrote:
Am Samstag, 20. Februar 2021, 00:23:57 CET schrieb Jan Engelhardt:
`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.
One could always set up an own OBS instance, configure and populate it with binaries from download.o.o and then build against that.
BTDT. Not for the crazy reasons brought up here, but to prove a bug in OBS that was not reproducible easily on build.o.o
@Carlos - I havent used rpmbuild since I use osc.
me too.
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.
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.
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.
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 buildsyour 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 yourlocal 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 2021/02/21 13:41, Axel Braun wrote:
Am Sonntag, 21. Februar 2021, 21:43:20 CET schrieb L A Walsh:
One can always have a risc-chip virtual machine that buildsyour 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
--- 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.
If a package builds+installs on OBS for the iphone, it won't do me any good as I don't have an iphone.
If the package I would build on OBS, would install, there wouldn't be a problem, but the rpm's coming out of OBS for TW are encoded in a new encoding that my existing TW machine+rpm cannot understand/read.
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....
--- Not if the binaries built on OBS are encrypted with a key I don't have. OBS builds rpms compatible with rpm-4.15 or greater. I still have a pre-4.15 rpm and am trying to upgrade it.
I have also tried building the newer rpm from the sources. That's not working either. Dominique made a joke about how she needed to install 'rpm-build' in order to build rpm. But rpm-build is part of the rpm package. So to build rpm >=4.15, you need an rpm-build that is >=4.15, but rpm-build is built when you build rpm.
Doing a build on an OBS system will yield rpm's that are not readable by rpm<4.15.
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.
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.
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...
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)?
and then go to current Tumbleweed from there.
Ciao Bernhard M.
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 Tue, Mar 9, 2021 at 9:04 PM L A Walsh suse@tlinx.org 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. The pitfall of rolling release distributions is that users *must* roll with it, or it won't work. If that's not the way you want to work, then switch to openSUSE Leap.
Second: If you're really struggling to update your system because of the compression change, then you can bootstrap an upgrade by downloading a container rootfs[1][2], extracting it, bind mounting your main rootfs into a directory in it, and using the container's RPM + Zypper/DNF to do it.
Third: Your quoting style is weird and breaks my client. How are you doing this and why?
[1]: https://build.opensuse.org/package/binaries/openSUSE:Factory/opensuse-tumble... [2]: https://build.opensuse.org/package/binaries/openSUSE:Factory/opensuse-tumble...
On 10/03/2021 03.23, Neal Gompa wrote:
On Tue, Mar 9, 2021 at 9:04 PM L A Walsh suse@tlinx.org 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 thiswas 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.
On 2021/03/09 18:23, Neal Gompa wrote:
First: You should be updating your Tumbleweed system continuously.
--- If a disk controller hadn't wreaked havoc on the main and backup arrays, this issue wouldn't have been near the problem that it became.
Nevertheless, I wasn't aware of how fragile or vulnerable a tumbleweed system would be nor that it would be a fulltime job to keep such a system running, especially given the number of breakages in functionality and compatibility associated with suse's bleeding edge. Just to upgrade from release to release took months as I reviewed new changes as I applied them in upgrading my server.
Second: If you're really struggling to update your system because of the compression change, then you can bootstrap an upgrade by downloading a container rootfs[1][2], extracting it, bind mounting your main rootfs into a directory in it, and using the container's RPM
- Zypper/DNF to do it.
---- DNF?
The main problem there is a matter of assessing the effects of something like:
1302 packages to upgrade, 2324 to downgrade, 1025 new, 299 to remove, 243 to change vendor, 19 to change arch.
on a working system and how well one might trust all package upgrades to be done seamlessly such that system downtime would be negligible.
Third: Your quoting style is weird and breaks my client. How are you doing this and why?
---- How am I doing this? I use the mystical powers of Thunderbird replying in text mode, um...I really don't know what you are talking about.
You aren't trying to use google's web client are you? I had all sorts of grief when I had to rely on it for a few months while my server was down. Google tends to play loose with Internet (and mail) RFC's/standards...
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 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.
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:
- 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.
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 Tuesday 2021-02-23 08:01, 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 witha forked tongue?
If someone doesn't already have their "upgrade ticket" in place, they can't get one.
You also can't upgrade from Windows 95 to Windows 10, so stop wanting to speak to the manager.
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?
Because the packages were rebuilt (this indeed was a manual trigger AIUI!), which makes them use all the new features they can, right away.
glibc the library is still binary compatible. The _programs_ aren't.
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.
On 2021/02/23 01:46, Simon Lees wrote:
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.
This has been discussed in the past, from an openSUSE perspective we would be far more interested in a statically linked zypper
==== From a SuSE perspective upgrading from SuSE 6.x, rpm is far more available.
in the end because we provide working upgrade paths for people on standard systems.
--- So anyone who does any customization or who has brought up a SuSE system via upgrades from SuSE 6.x or 7.x, is SOL. My system got this way because I upgraded from old suse and I didn't have the luxury of doing a wipe+install w/each upgrade. Good thing opensuse takes care of their longer term dupes, er customers...
I have 4.11.3 on my system and have tried installing 4.14.1and 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.
---- Unfortunately, tried installing 4.14.1 and then building = 4.14.1 wouldn't install, and building it didn't work either. Same for 4.15.1.
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.
--- Ho Ho, Ha Ha...like I can come close to doing things in the 'right' order -- so far, no order has worked, so I don't know how close I'll get to the "one true" order. Sorry, but everytime someone talks about the 'right' way, its in hind-site relative to what worked. Plenty of times the 'standard system' was messed up and went one direction in 1 release and another in the next release. If I went with the standard system -- there wouldn't have been zero chance of upgrading without a complete reinstall, multiple times.
So please understand -- standard system has required complete reinstalls in the past. You are absolutely right in that I don't have a standard system.
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.
---- Um, where are the .repo files I need to add to zypper for it to read the current dist? I've been using the repo/repodata/repomd.xml files for my own local cache and building a repository with that locally, but without downloading that first, zypper seems unhappy:
Error building the cache: [TW-OSS|http://download.opensuse.org/tumbleweed/repo/oss] Valid metadata not found at specified URL Warning: Skipping repository 'TW-OSS' because of the above error.
Tried repo/repodata (included --check in the zypper command and it *claimed* it was successfully added:
sudo zypper ar --check http://download.opensuse.org/tumbleweed/repo/oss TW-OSS Adding repository 'TW-OSS' ...............................................[done] Repository 'TW-OSS' successfully added Enabled : Yes Autorefresh : No GPG check : Yes URI : http://download.opensuse.org/tumbleweed/repo/oss
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 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.
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 11:29 +0100, Michal Suchánek wrote:
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.
Oh - that one I missed; so adding to my previous mail - compared to 4.11, we did not only change payload compression.
we actually use boolean dependencies in rpm.spec - which are supported from rpm 4.13 onwards (rpm 4.13 is from 2017 IIRC)
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 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.
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.
---- ^^yup
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.
---- And that's why I said that the sources for building the current packages were no longer included.
You can't build the current binaries unless you have some unknown set of binaries that came from some unknown set of sources that was posted for some number of days, then gone.
On 2021/02/23 02:23, Dominique Leuenberger / DimStar wrote:
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).
--- Right...a complete wipe of a working system that can't afford a complete wipe because nothing in opensuse upgrades package configs reliably, let alone if one uses an offline upgrade (install new packages over old).
The sources for the in binaries in TW now, can't be built on user systems unless they maintained the TW-treadmill every day. If your system goes out, standard or not, suse doesn't support upgrades.
If there was an archive of all the TW binaries from when I got cut off, to today, it would be doable, though very unpleasant. It's not that I didn't have a standard system, but that TW doesn't supply the intermediate upgrade-bits past a few day expiration limit.
I.e. subject says it -- can't rebuild from sources because I can't download readable rpm binaries that contain the build tools.
(Thus I'm rehauling my download stuff to handle leaping)
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/C42COR346BPMB7UVV42MJTKXIWXNE5V2/
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?
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.
On 2021/02/19 06:00, Dominique Leuenberger / DimStar wrote:
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.
---- No -- we are talking about rpm. So install rpm from 10.2 and use it to install + upgrade from the current rpm-sources using the rpmbuild in 10.2.
Might help if you use the same product.
The rpm I have doesn't read the rpm's in the new compressed encoding. Would it have been that painful to have rpm that you ship today be installable on any tumbleweed system by statically linking it?
Then someone can upgrade to some distro-specific-recoded rpm after that. Just having a cutoff at >=4.15 = only rpm that will read new rpm-formats, while <4.15 can't install 4.15 sorta sucks.
People think shared libs are the answer because of security fixes, but not every program links with every lib. Furthermore, there are programs that are alot more useful to have "working" than worry about patching for a security fix that might happen once in a blue moon. If rpm needs a security fix, create 1 new static rpm that works everywhere.
This is a problem -- creating static programs for things being able to open your rpm's old+new, is 1 program. Same might be true for a boot shell and 'mount'. Somethings are more important than being fragile and subject to not running on a system w/different libs or a different installation encoding.
середа, 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.
-
Aaron Puchert -
Axel Braun -
Axel Braun
-
Bernhard M. Wiedemann -
Carlos E. R. -
Carlos E. R. -
Carlos E.R. -
Daniel Morris -
Daniel Noga -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Johannes Meixner -
John Paul Adrian Glaubitz -
L A Walsh -
L.A. Walsh
-
Michal Suchánek -
Mykola Krachkovsky -
Neal Gompa -
Rodney Baker -
Simon Lees -
Stefan Seyfried -
Syds Bearda -
Thorsten Kukuk