Debian Developers Discuss Process For Salvaging Packages

[phoronix]

Phoronix: Debian Developers Discuss Process For Salvaging Packages

While Debian has tens of thousands of packages in its archive and users often tend to cite the size of a package archive as one of the useful metrics for evaluating a OS/distribution or package manager's potential, not all packages are maintained the same. In acknowledging that not all packages are maintained to the same standard and some ultimately slip through the cracks, Debian developers are discussing a salvaging process...

http://www.phoronix.com/scan.php?page=news_item&px=Debian-Package-Salvaging

[kpedersen]

What we do at work when we no longer actively develop an internal program or library is put it into maintenance mode.

Maintenance mode usually means simplify it. Remove as many dependencies as possible (i.e replace libpng, libjpeg, sdl_image with a single file alternative like lodepng or std_image). Reduce its build system to the bare minimum (sometimes a single Makefile with no incremental build support (i.e no .d files generated)).

Yes, it means that security issues can creep in (i.e if a bug is found in stb_image then it isn't fixed when the system libraries are updated) and yes it also means that making it each time does a "full build". But at least it requires almost zero work to get it to build. Since it *is* in maintenance mode after all, it souldn't need to be built all that much anyway.

But it is there and works when you do need it

[R41N3R]

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

[Candy]

... a new running gag

[starshipeleven]

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

[starshipeleven]

... a new running gag

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

[kpedersen]

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

If you run a Debian Etch chroot in a Debian stretch kernel, you will see it says kernel wrong version and libc is incompatible.
The same will be the case with flatpacks. It is a little bit shortsighted. A flatpack can only keep a software package alive for 2 years tops.

Perhaps a correct solution should be invented instead?

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.

[oiaohm]

If you run a Debian Etch chroot in a Debian stretch kernel, you will see it says kernel wrong version and libc is incompatible.
The same will be the case with flatpacks. It is a little bit shortsighted. A flatpack can only keep a software package alive for 2 years tops.

What the hell are you talking about. I have a etch chroot on the current debian testing(buster) and it works I in fact have older that works. Etch is older than stretch maybe you have those names backwards. Backwards you will see that error as in stretch chroot on a Etch kernel.

Etch is debian 4 and Stretch is debian 9.

Part of the debian testing system https://piuparts.debian.org/ is a stack of chroots running older debian on newer kernels. 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.

http://snapshot.debian.org/

Debian has the snapshot system that means you can install packages from 2005 by install a 2005 distribution in a chroot on current Debian. This proves something with complete runtime has a chance of 10 years. The failure is not glibc its opengl the recent debian conference had a video covering work attempt to fix this in fact the demo in that conference was etch chroot running on stretch running a few programs no longer in the current package.

[NotMine999]

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

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

How does that solve anything?

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

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