Debian elects new project leader, PPA support proposed
distrowatch.com
distrowatch.com
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.
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).
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.
Isn't that pretty much the whole point of package repos in the first place?
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.
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.
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.
> 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.
As someone who is unfamiliar with this term, can someone please summarize what it means? What makes it appealing?
Thank you in advance.
This is particularly helpful when working with LTS (Long Term Support) versions. I have many servers who are still 12.04. I need to install Node 0.12, but the official packages are stuck in 0.6. PPAs make this possible without having to build from source or otherwise hack your way around the system.
This would be really interesting to see on Debian!
Honestly I think PPA's only real-world appeal will be for desktop Debian users.
No one with any rational thought process is going to use a PPA sourced package on a server environment.
edit: missing closing parenthesis.
http://nginx.org/en/linux_packages.html
The PPA is unofficial.
This offers a measure of security agains malicious binaries ...
Even if Launchpad builds the binary package, Ubuntu does not review packages' content.
The trust model for PPAs requires users to trust PPA owners, not Ubuntu.
What could use some work is the documentation/startup instructions for how to run a Debian package repository effectively (my company has a company-wide repository for internal packages with quality guidelines and a decent amount of review, but this is not without issues). https://wiki.debian.org/HowToSetupADebianRepository exists, but there's ten different tools listed of varying quality and there really, really needs to be a "This is how you need to do it." method.
That said, I really do like the model of "submit source package, server handles the logistics of building it for N architectures".
Your approach totally works, but we typically run into the problem of "system administrator has thing that works for them on a couple systems", then it's rather difficult to get everyone using the same tool so that people can interoperate (or bikeshedding about which one has a nifty feature and changing tools every six months) -- or worse, breaking something because they didn't understand how the other tool's process was different.
If different teams want to build their own packages (using whatever toolchain they want, which results in a .deb) and have them hosted on the company repo server(s) - why should they care how the hosting works? Have them supply (usually an upload of some kind) the built (and if necessary, signed) package files, and their job is done.
I know it's hip and cool to treat "devops" as meaning "developers get their hands dirty with ops and we have no separation" but that's a ridiculous interpretation of the concept.
There is a definite and identifiable skillset involved in system and network administration (aka Ops, Infrastructure, or historically "IT department").
There is no reason developers can't learn these skills (I actually went the other way, studied Network Engineering, learnt dev later, now I do both) but it's stupid to assume that just because a developer can install vagrant, that he or she is qualified to run or make key decisions about core infrastructure and services.
I completely agree that developers shouldn't be making ops decisions and have scars to prove it.
I wasn't saying the existing systems are foolproof, but I don't think PPA's add anything to help the problem you're describing.
Ah and I just realise you were originally replying to the bit about "dpkg-scanpackages and a Makefile”!
It could be that I've just not bumped into problems which require them, but I've not found a project which offered features above the set this gives you where the trade-off is worth the complexity. "Everything works this very simple way, there's almost nothing to learn" is very persuasive.
[e.g. Use a Debian mirror to pull from if there isn't a local substitute]
That can (and is) done today - host the compiled packages in a reprepro repo, and add it as a source for apt.
If the package is a backport, apt will upgrade/install it, as it's a higher version than that in the official repo. If the package is from outside debian, apt will updgrade/install it, as it can't find any other package with that name.
I realise you said "prepackaged" but the steps to get a basic reprepro repo setup, and the steps to (e.g.) pull a testing package and build it under stable, are documented numerously online - if the existing options are too complex for the audience you have in mind, I think building (and maintaining) their own packages is not a reality for that audience.
edit: s/of/for/
I think my problem at this point is this:
Every time I have to do manual steps for something that is a one-off [which, let us be honest, I'm not going to automatically configure a deb repo since I only re-do it every few years].
Yes, it isn't /hard/ but that doesn't change the fact it consumes time I could spend elsewhere if I had a standard iso from Debian I can just spin up on a VM or a bare metal server.
Atm, my major limiter is how much time I spend building/maintaining environments vs. programming.
Keeping repositories synced between versions of Debian and architectures is slightly harder but doable.
Best practices for handling uploads from individual developers, making sure all dependencies are included at the same time when a package is published is hard.
Running something like the official Debian unstable -> testing transition of packages (with QA/testing in that loop), and figuring out what rebuilds are necessary is very hard.
In fact, I wrote tools to do this many years ago:
https://gitorious.org/debian-repo-packager creates packages for a bunch of repos, including PPAs
http://chriswarbo.net/git/service-packs.git provides a GUI for creating "service packs": packages containing a repository, generated from a list of packages and their dependencies.
Your way: 1. Download deb package. 2. Locate downloaded deb package. 3. Install deb package. 4. Update package lists. 5. Install actual, desired package.
PPA way: 1. Add PPA. 2. Update package lists. 3. Install actual, desired package.
Since in this case your binary package would consist of only a text file, building a full-fledged deb package could be considered overkill.
Besides that, installing your binary package would give a signature verification error, requiring the user to manually install your GPG key. But Launchpad and apt-add-repository handle that automatically.
And that's just for users. Think about the difference between the steps involved for repo authors: they could setup and build a package just to install a text file...or they could go to Launchpad, click a few buttons, and have a PPA ready.
> 2. Locate downloaded deb package.
> 3. Install deb package.
> 4. Update package lists.
> 5. Install actual, desired package.
Well, it's been a while since I wrote my proof-of-concept, but I managed to get the steps down to:
1. "Open with gDebi"
2. Install package
3. Install "actual, desired package"
The package list can be refreshed automatically using "postpone" (which was new to Debian at the time, but is pretty widespread now).
Also, the "service pack" idea is even more powerful. The package contains the repo, along with a metapackage depending on the "actual, desired package(s)" for which the repo was generated. The repo is unpacked to disk, added to sources.list.d, then the metapackage is installed.
The original idea was to package the closure of a bunch of packages; eg. we can say "include 'gimp', 'inkscape' and 'blender', but not 'ubuntu-desktop'"; that would generate a repo containing gimp, inkscape, blender and all of their dependencies, except for those implied by the existence of ubuntu-desktop. This repo would be packaged up, along with a metapackage depending on gimp, inkscape, blender and ubuntu-desktop. I also made an option to package up security updates.
A nice consequence is the ability to distribute all of the dependencies of a package, but they'll only be used as fallbacks; if newer versions are available, they'll be used instead.
Of course, updates can free up disk space as the need for fallbacks diminishes.
The message in the removal email mentions that dpkg triggers fulfil the same task now, have you ever tried/managed to use dpkg-triggers in the same way? It strikes me as likely being impossible as they're run by dpkg itself, which needs to exit before the update can begin...
At this stage it seems like a solution to do this would need to re-package `postpone` for >= Jessie (which isn't impossible, it just makes for one more thing to support).
No, I've not looked at this problem for ~6 years. APTonCD achieves some of the goals I had, so when that became popular I abandoned my attempts.
Upstart predates systemd by over four years. I just checked the initial release dates on Wikipedia to confirm.
https://en.wikipedia.org/wiki/Upstart [August 24, 2006]
vs.
https://en.wikipedia.org/wiki/Systemd [30 March 2010]
I've done the above both with and without a PPA for Ubuntu. Without a PPA you need to have separate virtual machines for each architecture (and if you don't have physical machines and/or hardware virtualization, this will be really really slow). And you also need a VM (or perhaps a chroot/pbuilder environment) for each distribution version, if you target more than one version.