Debian Developers Discuss Process For Salvaging Packages

[oiaohm]

It simply cannot work for any comprehensive software. Linux simply removes (or replaces) too much in its kernel to allow this as a solution. The closest UNIX ever got to this kind of backwards compatibility was i.e a Solaris 8 zone in Solaris 10 (and even then, a lot of software broke). And in comparison to Linux, Solaris is (was) incredibly stable as a kernel and ABI. The kernel even had compile time flags to enable backwards compat, something that Linux only maintains for a year tops (FreeBSD for about 5 years).

What you said simple cannot work. In fact works every day of the week. Linux kernel is backwards compatible on it user-space that newer kernel for over 95 percent of applications ever made for Linux will run on it.

Linux kernel syscalls and userspace ABI interfaces were choose as the Unix standard syscalls and userspace ABI because they are in fact most stable out of any posix OS. More stable than Solaris syscalls and userspace ABI.

Solaris has in kernel binary driver compatibility layer Linux kernel does not have that.

https://www.kernel.org/doc/Documentation/ABI/README

This directory documents the interfaces that the developer has defined to be stable. Userspace programs are free to use these interfaces with no restrictions, and backward compatibility for them will be guaranteed for at least 2 years. Most interfaces (like syscalls) are expected to never change and always be available. Really the please note they say the stuff is there basically forever it promised at least 2 years .
If you look in the removed directory that in fact list everything removed ever from the userspace interface

https://www.kernel.org/doc/Documentation/ABI/removed/

Its 9 things covering the time frame from Linux 2.0 kernel to current. That is the no syscall interfaces. Syscalls are just as stable.

Yes a year tops claim is bogus. Min a syscall/userinterface declared stable must last on Linux is 2 years. Reality is 99percent syscalls/ userspace interfaces declared stable in Linux kernel are forever never to change how they respond to userspace applications.

Yes a removed Linux syscall or userspace API interface unless has to be removed on security grounds(insane rare) has to exist mainline for 2 years as stable then 2 years in deprecated before being removed so the normal min is at least 4 years before the interface could disappear. These long time frame min explain why adding new userspace syscalls or userspace ABI interfaces have very heated debates also due to those heated debates the interface is normally designed right so never changes.

Linux kernel has very few backwards compatibility flags mostly because they are not need because the API/ABI to userspace almost never removed anything and the amount removed is so minor it not funny and Linux kernel does not bother with kernel ABI for driver stability. .

Solaris 8 zone on Solaris 10 has more syscall differences to Solaris 8 so higher application failure rate than using a debian 2.0 chroot on current debian testing . Yes debian 2.0 is 1998 so basically 20 years where Solaris 8 to 10 is only 5 years the solaris change rate of kernel userspace interface change rate to applications is over 4 times faster than the Linux kernel.

The year tops claim is way out as the real figure on the Linux kernel is 4 years min except for insanely rare condition that something has to be removed on security grounds in all of Linux history this has only happened once.

Also do check the Linux kernel config files in distributions for the compatibility flags enabled watch out for CONFIG_IA32_AOUT yes this is enabled in current day Debian kernel is only there for running binaries from debian 1.0 as debian 2.0 uses ELF instead of COFF binary format. So the current day debian kernel is configured to be able to run over 95% of every userspace application ever made for debian almost all enterprise Linux Distributions are this way. The problem is not the linux kernel for application compatibility its userspace stuff like opengl libraries.

Debian/RHEL chroots due to the Linux kernel(and the configuration they choose) makes Solaris zones for backwards compatibility look like a joke. Due to most distribution kernels following Debian/RHEL lead items like flatpak can downright work.

Yes there is a lot of talk about the Linux ABI being unstable this is only the in kernel space driver ABI. The userspace ABI of the Linux kernel is the most stable thing out there by miles with the standard enterprise configurations I know of no OS kernel that can beat Linux kernel on backwards compatibility for user-space applications.

Most Linux backwards compatibility issues are
1) run-time issues like old opengl libraries not knowing how to talk to new hardware and newer library of opengl having some conflict if used with older version of library application is using there are solutions being worked on to fix this at long last.
2) Package management in most distributions choosing security over backwards compatibility so only have the most current version of stuff installed.
Not one of these issues requires any kernel modification to fix. The runtime issue will most likely be solved by dlmopen work in glibc to allow libraries using newer versions of libraries to be mixed with applications using older versions of libraries.

[calc]

The "flatpack package maintainer" will still be Debian developers, so it will support all archs they want to support. Flatpack per-se can support whatever, it's not arch-specific. Flatpack, unlike Snap allows anyone to host their own repository so Debian could make their own and have 100% full control over it. Total bullshit question even for the topic in that thread.

Isn't the point of flatpak to have simplified way to install packages on all distributions from a centralized location, flathub, maintained by the original software author, so that RH/Fedora doesn't have to put in the work to maintain a distribution any longer?

In that case the Debian Developers would not be the maintainers the original upstream would be. If Debian ran their own flatpak repo they would need to repackage the distribution in flatpak instead of debs for little to no real gain. The only thing it would buy is allowing old code to bitrot, not sure that is a plus, and that would also be at the cost of security problems and massive library duplication (including in RAM) from many different revisions of runtime if they did leave the code to rot on ancient runtimes.

It sounds like your proposal is more like the previous failed attempt at unification of all distributions, United Linux.

flatpak does have good specific use cases, primarily 3rd party proprietary software and updated packages for LTS distributions (CentOS/RHEL/Ubuntu LTS/etc), but outside that really is a bad idea for general use.

[starshipeleven]

You ignored and did not address the largest points they made. lol

I didn't address bullshit questions and tangential ones for the situation discussed in this thread (which is moving only the "unmaintained" applications to flatpack, not the whole Debian), let me break this down.

P1. How many architectures do they support? How many of those can you fit on your Pi?

The "flatpack package maintainer" will still be Debian developers, so it will support all archs they want to support. Flatpack per-se can support whatever, it's not arch-specific. Flatpack, unlike Snap allows anyone to host their own repository so Debian could make their own and have 100% full control over it. Total bullshit question even for the topic in that thread.

P2. I can't see Debian turning away from the simplicity, speed, efficiency, and much smaller size of packages that are built from source using shared libraries, to embrace flatpaks as default. They are huge and bloated (300 MB for Telegram-desktop) and have trouble with respecting your theming, too.

This question is tangential to the proposal of RAINER in this thread, I ignored it.

P3. ok, they have their uses every now and then, but they should not replace regular package management.
unless we want to hop on the "get new hardware every year to keep up with the software" train...

Same as P2.

On top of that the json format is much uglier and harder to read than the debian packaging format or rpm spec format.

I don't see a difference worth crying about. I personally like more the "all in a single file" approach, while Debian has files you need to edit all over the place (yes I build some debian packages for some scripts and tools), but neither is "bad" by any means.

[Vistaus]

Or just get rid of them in the repository and provide one time a flatpak 😉

Not before the apps are rewritten in Rust

[kpedersen]

The LTS branches of Debian do this yes the ones supported for at least 5 years you also find the CIP versions doing this as well for over 10 years.

It simply cannot work for any comprehensive software. Linux simply removes (or replaces) too much in its kernel to allow this as a solution. The closest UNIX ever got to this kind of backwards compatibility was i.e a Solaris 8 zone in Solaris 10 (and even then, a lot of software broke). And in comparison to Linux, Solaris is (was) incredibly stable as a kernel and ABI. The kernel even had compile time flags to enable backwards compat, something that Linux only maintains for a year tops (FreeBSD for about 5 years).

I guess time will tell though wont it

(also, it doesn't quite solve the issue if we do all manage to move over to POWER or RISC-V one day. Qemu-static is nice but a lot of performance is lost. If people are not thinking of this as a possibility, perhaps even 10-20 years down the line, then they aren't really thinking about proper digital preservation.)

[calc]

For the sake of having some fun at poking holes at their claims I'll address the most important point they raise...

You ignored and did not address the largest points they made. lol

P1. How many architectures do they support? How many of those can you fit on your Pi?

The flatpak package maintainer decides and it certainly won't match the list of arch Debian at least tries to support.
Debian maintainers often do porting work to get a package working on an arch it doesn't work on.

P2. I can't see Debian turning away from the simplicity, speed, efficiency, and much smaller size of packages that are built from source using shared libraries, to embrace flatpaks as default. They are huge and bloated (300 MB for Telegram-desktop) and have trouble with respecting your theming, too.

The bloat is actually by design and is a side effect of the compile once run anywhere goal.

Which leads to the final point:

P3. ok, they have their uses every now and then, but they should not replace regular package management.
unless we want to hop on the "get new hardware every year to keep up with the software" train...


On top of that the json format is much uglier and harder to read than the debian packaging format or rpm spec format.

[starshipeleven]

You can read (link below), what debian users and developers think about flatpak

http://forums.debian.net/viewtopic.php?f=20&t=136863

Wow, a totally unexpected list of plain wrong bullshit from 6 random people that aren't even developers? With obligatory Pottering bashing, of course. Yeah that's a totally acceptable sample size for Debian userbase.
Note: I'm convinced that debian user/developer base will be more or less be for "doing the way we always did" because Debian does attract those types, but that thread means nothing.

For the sake of having some fun at poking holes at their claims I'll address the most important point they raise...

flatpacks make it harder to see the source? "does not look like to him"? Did this person do more than just write uninformed opinions, like for example looking at the package manifests where you can see what sources are taken and assembled in what way to create a flatpack?

This for example is taking a pre-compiled release tar.gz from the developer's site https://github.com/flathub/org.geoge....GeoGebra.json

This is pulling a source archive, applying patches from its folder and compiling stuff https://github.com/flathub/net.sourc...forge.Teo.json

Look at the complexity, the extreme difficulty of the json language they used to assemble those manifests. Of course these are simple applications, more complex stuff will require more work, but you can see that it's basically a thing anyone with basic understanding of command line can read and modify on his own.

You can git clone the source repo of the package (to get the manifest, icons and patches and whatnot) and then run locally the flatpack-builder tool to assemble or compile the package according to its manifest http://docs.flatpak.org/en/latest/bu...roduction.html Or edit the manifest to do different stuff, include your own patches to the same source, whatever you can also do with Debian's source packages infrastructure.



The thoughts of random lazy people on a forum won't stop the Flatpackalypse and you know it. I repeat: be afraid.

[Candy]

Be afraid, be very afraid. (of the above post)

You can read (link below), what debian users and developers think about flatpak

http://forums.debian.net/viewtopic.php?f=20&t=136863

[starshipeleven]

Place an unmaintained package into another format where that same package could possibly go unmaintained?

How does that solve anything?

Flatpack isn't "another format". It ships versioned libraries for it too, so it can run with the same exact libraries it was last packed and tested with, forever.

This isn't what happens in a distro, where things are updated evey now and then, and for sure between major releases.

In most cases a software breaks when you try to compile it with libraries at different (newer) version, as the libraries evolve with time and new bugs appear, and so on. Compilers also change with time and may require cleanups and changes to compile stuff that before was being compiled fine.

If you make a Flatpack package, you make sure that the application compiles and works with the libraries you decide to ship with it (and/or with some Flatpack common dependencies that are versioned too and won't change in the future), and then you leave it there, in binary form.

It will never need to be re-compiled or updated, as it will keep using the same libraries as it always did.

Answer: Repackaging an unmaintained package does not solve anything; like rearranging deck chairs on the Titanic.

Protip: if something looks so obviously stupid, it might be wiser to just ask if there is something you didn't know about it, because not a lot of people are so obviously stupid to believe that repackaging a package in a different format can have any effect.

[starshipeleven]

If you run a Debian Etch chroot in a Debian stretch kernel, you will see it says kernel wrong version and libc is incompatible.

I have to concur with oiaohm, I run older versions of Debian (not so old, but still one or 2 versions older) in a chroot on a modern Debian to run some business "applications" that aren't (or will never be) ported over to latest Debian and the customer does not feel like leaving the server happily running a with an OS that stopped receiving security patches 5 years ago.

They work fine as long as you only need commandline and server-y things.

Edit: Heck, flatpack isn't even going to be around in 2 years. When it comes to digital preservation, you need to think much harder! The topic of lifespan is a definate weakness of the open-source software community.

Flatpack is actually one of the projects that has the best shot at digital preservation, by its own nature it can keep shipping old runtimes indefinitely which will run indefinitely on Linux kernel because it's API stability (more like versioning, but anyway) towards userspace.