PPAs are a thing of the past, I think. A much better way forward would be to implement a truly transactional and functional packaging system (a la nix/guix), where updates could be rolled back seamlessly. This would allow many interesting features, including aggressive update cycles and multiple versions of the same package installed in the same system.
It'd help Debian, which thanks to its social contract is a very nice distribution but has become somewhat stagnant due to overly bureaucratic procedures.
PPAs aren't a replacement for the package management system. They're just another repo. A transactional packaging system would be cool, but it's a much bigger change than implementing PPAs.
They fulfill different goals. I've reached the stage where I don't always need the latest software—I'm more concerned with something stable that receives prompt security patches. For this reason, I've been sticking with the LTS Ubuntu releases rather than upgrading twice a year (though Kubuntu 15.04 has been awfully tempting for me). I guess I'm getting boring with "old" age—I built my systems following Linux From Scratch back in the day; now, I just want a system that works.
A transactional packaging system would definitely ease the pain of running newer software, but I don't want to take the time to try it—I'd rather stick with the release cycles provided by the distro as a whole. In this situation, PPAs are great for when I want to install software that isn't in the official repos (or is at an older version).
Both have the goal of to make it easy to get newer software, or software from other sources, within the same management interface, and without breaking all the other packages of the distro. But transactional packaging systems does get to those goals, while PPAs just maybe get there, for a time, but always turn-out breaking something.
But if you are using PPAs to create different lists of released software, so you can keep you stable software while everybody else wants to move to something newer, transactional packaging does not have that goal. Although it makes the job of maintaining such PPA much easier.
> A much better way forward would be to implement a truly transactional and functional packaging system (a la nix/guix), where updates could be rolled back seamlessly.
It doesn't work like nix/guix, but Ubuntu are doing what you describe with Click and Snappy. Click is already live on Ubuntu phones.
> PPAs are a thing of the past, I think. A much better way forward would be to implement a truly transactional and functional packaging system (a la nix/guix), where updates could be rolled back seamlessly.
Exactly, and this is what CoreOS does.
I see this as the role that containers fill. Systemd already supports what you describe, via systemd-nspawn, which allows native containerization, and with btrfs, which allows either persistent or ephemeral containers to be built off of a "template"[0].
Systemd is already able to run Docker images and even pull them directly from the Docker registry, so I'd rather see containers adopted as the new model of vendoring[1] rather than PPAs.
And since Debian already uses systemd now, this should be very easy to integrate.
[0] I put "template" in quotation marks because I'm using the term loosely here; nspawn uses the word template to refer to something different.
[1] Let's be frank: while PPAs can do more, 90% of the PPAs I was asked to add when I used Ubuntu were basically aimed at solving vendoring and/or versioning issues.
> Systemd is already able to run Docker images and even pull them directly from the Docker registry, so I'd rather see containers adopted as the new model of vendoring[1] rather than PPAs.
After having dug into Docker containers for a few weeks to identify what we have to be aware of as we roll out to them at work, I would rather not.
NAT overhead, asymmetric TCP routes, devicemapper inefficiencies, 400+mb images, new toolsets for debugging, unsigned images (though at least the foundation to support them exists now)...
Until these bumps are sorted out I'm more than happy to deal with a few rare incompatibilities from package upgrades.
> After having dug into Docker containers for a few weeks to identify what we have to be aware of as we roll out to them at work, I would rather not.
> NAT overhead, asymmetric TCP routes, devicemapper inefficiencies, 400+mb images, new toolsets for debugging, unsigned images (though at least the foundation to support them exists now)...
You don't have to use Docker images (and systemd actually handles all of the issues you point out better than Docker anyway). I only mentioned Docker because it allows people to use existing Docker images without any extra work.
I know. It's very nice. That's what I use everyday on Arch. Still, I feel functional package managers buy you a few more advantages. The whole package tree doesn't need to be in sync, and package hashes mean you have pretty strong guarantees things won't break due to dependency mismatches.
I don't understand how nix/guix deprecates the need for PPAs. PPAs allow you to offer a collection of packages, and updates, outside of the main repository and allows users to 'opt-in' to those packages and updates, which would otherwise not be visible to him. It seems to me nix/guix is entirely orthogonal to that.
It would be cool to have some sort of docker style version control. Docker has all versions in the same docker file, they just onion the newer ones on top. Roll back and version control would be really easy!
PC-BSD is doing this. They're using ZFS snapshots to get a COW version of your FS before an update so if something goes wrong you can instantly roll it back (even boot into it from the boot loader)
It'd help Debian, which thanks to its social contract is a very nice distribution but has become somewhat stagnant due to overly bureaucratic procedures.