8 ms·

Debian elects new project leader, PPA support proposed

80 points by Iuz 11y ago

iguessthislldo 11y ago
PPA Support in debian.... please yes.
- structural 11y ago
  This is by far the most annoying part of having to support random Ubuntu systems. PPA package quality has tended to be lower over the years, typically not on first install, but on upgrade/uninstall/dependency management paths that don't rear their head until months later (everything appears to work at first! this is great!) 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 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".
  - regularfry 11y ago
    I believe http://www.aptly.info/ http://www.aptly.info/ is aiming for that. I just use dpkg-scanpackages and a Makefile, but I guess that's not for everybody.
    - structural 11y ago
      Thanks for the link. Aptly looks like a nice tool. 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.
      - stephenr 11y ago
        Aptly is about hosting packages only right? 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.
        structural 11y ago
        See my other comment, but hosting's the easy part, managing packages from "packaged, this afternoon, works on dev's machine" to "tested and works for a couple thousand people, let's deploy this" is the challenge. The bad ways of doing this involve every team setting up their own repos (differently! ha!) to test things before pushing them up a level. This happens a lot, absent defined structure. So does things like e-mailing packages around, two people bumping a version number to the same thing, and so on. I completely agree that developers shouldn't be making ops decisions and have scars to prove it.
        xorcist 11y ago
        Why do you run into that situation? Do your developers not have access to your interal repo? Emailing packages around sounds like a symptom of a process problem.
        stephenr 11y ago
        Right yes I understand now, and agree. 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”!
  - fweespeech 11y ago
    Yeah, I agree with you. I think PPAs are a nice feature for end users [who don't mind nuking their computer if things go awry] but a prepackaged way to create your own mirror of Debian and then substitute packages as-desired would be lovely. [e.g. Use a Debian mirror to pull from if there isn't a local substitute]
    - stephenr 11y ago
      It sounds like what you want is your own repo with either backported packages or packages not available in any Debian repo? 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/
      - fweespeech 11y ago
        Thanks and that is a valid opinion. 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.
  - ice799 11y ago
    I built https://packagecloud.io https://packagecloud.io to help make creating, hosting, and installing APT (and other) repositories easier. Check it out :D
    - structural 11y ago
      Looks neat. My intranet is completely airgapped. Is your enterprise offering self-hosted? "Works with your infrastructure" on your webpage is very ambiguous.
  - stephenr 11y ago
    Do you mean instructions to run a mirror of the official repos, or a repo with your own packages?
    - structural 11y ago
      Hosting a repo is the easy part to figure out. 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.
      - stephenr 11y ago
        So, you didn't actually answer my question directly, but it sounds like you're talking about your own packages?
        structural 11y ago
        Yes
ColinDabritz 11y ago
PPA = Personal Package Archive As someone who is unfamiliar with this term, can someone please summarize what it means? What makes it appealing? Thank you in advance.
- jameskilton 11y ago
  PPAs are how people build custom packages for Ubuntu, most often to support newer versions of software over what's available in the official package list. 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.
  - fideloper 11y ago
    Typical use cases for me our to get the latest stable Nginx, PHP, HAProxy and similar popular packages without having to upgrade to a non-LTS release of Ubuntu. This would be really interesting to see on Debian!
    - stephenr 11y ago
      These types of things are already available (and I would wager much more stable than the type of thing found in PPA's) through third-party repositories like http://Dotdeb.org http://Dotdeb.org 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.
      - reubenmorais 11y ago
        PPA support would just make it easier and safer to add repositories like http://dotdeb.org http://dotdeb.org to your setup. I don't see how PPAs are any worse than manually adding entries to your sources.list file. They're almost the same thing, except the former a bit more automated.
nextos 11y ago
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.
- sp332 11y ago
  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.
  - nextos 11y ago
    I agree, but I see them as a patch to get something that could be more cleanly achieved with a transactional packaging system.
    - organsnyder 11y ago
      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).
      - marcosdumay 11y ago
na85 11y ago
Rather upset to see Ubuntu moving away from Upstart.
- pekk 11y ago
  That happened shortly after the infamous Debian vote
  - kleiba 11y ago
    Care to elaborate (on both, i.e., what's the upstart issue and how a Debian vote relates to it)? It seems I missed all of that, but would be grateful to learn more.
    - notatoad 11y ago
      Ubuntu created upstart around the same time systemd was created, both meant to replace the classic init system. Debian voted to adopt systemd as their new init system instead of upstart, and so now ubuntu, because of it's debian dependencies, will be dropping upstart and moving to systemd as well.
      - kleiba 11y ago
        Ta!
      - rlpb 11y ago
        > Ubuntu created upstart around the same time systemd was created, both meant to replace the classic init system. Upstart predates systemd by over four years. I just checked the initial release dates on Wikipedia to confirm. https://en.wikipedia.org/wiki/Upstart https://en.wikipedia.org/wiki/Upstart [August 24, 2006] vs. https://en.wikipedia.org/wiki/Systemd https://en.wikipedia.org/wiki/Systemd [30 March 2010]
    - tobik 11y ago
      Here is the relevant HN thread with some discussion about it: https://news.ycombinator.com/item?id=7203364 https://news.ycombinator.com/item?id=7203364
yarrel 11y ago
PPAs as they stand are an antipattern. If Debian brings some order to the chaos of unsupported, incompatible and duplicated PPA repos then that would be a win on balance. But if they just bring that chaos to Debian then it certainly won't.
shmerl 11y ago
How are PPAs different from current unofficial Debian repositories?
- lukaslalinsky 11y ago
  The general idea of PPAs is that they are "personal". You don't need to set up anything to create your own repository. Just build the package, upload it to the PPA and you have a fully working APT repository.
  - samuellb 11y ago
    You don't even have to build the package. You just create a source package and upload it with "dput" or similar. Then the PPA servers will build your package for multiple architectures (usually x86 and x86_64, but a Debian PPA might build for all Debian architectures, which are many more). It is also possible to build for multiple versions easily by changing the target distribution in the changelog file. 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.
chriswarbo 11y ago
I never understood PPAs. Ever since /etc/apt/sources.list was split up into /etc/apt/sources.d, we've been able to manage repositories using files. Since we already manage the rest of our system files with packages, why not do the same for repos? Dump a sources.d entry, and possibly a GPG key, into a .deb package and give that to users, rather than instructions on how to enter non-standard URLs into a vendor-specific GUI. In fact, I wrote tools to do this many years ago: https://gitorious.org/debian-repo-packager https://gitorious.org/debian-repo-packager creates packages for a bunch of repos, including PPAs http://chriswarbo.net/git/service-packs.git 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.
- alphapapa 11y ago
  That's a sensible way. But consider the steps involved: 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.
  - chriswarbo 11y ago
    > 1. Download deb package. > 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.

80 points by Iuz 11y ago

iguessthislldo 11y ago

PPA Support in debian.... please yes.

structural 11y ago
This is by far the most annoying part of having to support random Ubuntu systems. PPA package quality has tended to be lower over the years, typically not on first install, but on upgrade/uninstall/dependency management paths that don't rear their head until months later (everything appears to work at first! this is great!) 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 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".
- regularfry 11y ago
  I believe http://www.aptly.info/ http://www.aptly.info/ is aiming for that. I just use dpkg-scanpackages and a Makefile, but I guess that's not for everybody.
  - structural 11y ago
    Thanks for the link. Aptly looks like a nice tool. 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.
    - stephenr 11y ago
      Aptly is about hosting packages only right? 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.
      - structural 11y ago
        See my other comment, but hosting's the easy part, managing packages from "packaged, this afternoon, works on dev's machine" to "tested and works for a couple thousand people, let's deploy this" is the challenge. The bad ways of doing this involve every team setting up their own repos (differently! ha!) to test things before pushing them up a level. This happens a lot, absent defined structure. So does things like e-mailing packages around, two people bumping a version number to the same thing, and so on. I completely agree that developers shouldn't be making ops decisions and have scars to prove it.
        xorcist 11y ago
        Why do you run into that situation? Do your developers not have access to your interal repo? Emailing packages around sounds like a symptom of a process problem.
        stephenr 11y ago
        Right yes I understand now, and agree. 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”!
- fweespeech 11y ago
  Yeah, I agree with you. I think PPAs are a nice feature for end users [who don't mind nuking their computer if things go awry] but a prepackaged way to create your own mirror of Debian and then substitute packages as-desired would be lovely. [e.g. Use a Debian mirror to pull from if there isn't a local substitute]
  - stephenr 11y ago
    It sounds like what you want is your own repo with either backported packages or packages not available in any Debian repo? 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/
    - fweespeech 11y ago
      Thanks and that is a valid opinion. 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.
- ice799 11y ago
  I built https://packagecloud.io https://packagecloud.io to help make creating, hosting, and installing APT (and other) repositories easier. Check it out :D
  - structural 11y ago
    Looks neat. My intranet is completely airgapped. Is your enterprise offering self-hosted? "Works with your infrastructure" on your webpage is very ambiguous.
- stephenr 11y ago
  Do you mean instructions to run a mirror of the official repos, or a repo with your own packages?
  - structural 11y ago
    Hosting a repo is the easy part to figure out. 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.
    - stephenr 11y ago
      So, you didn't actually answer my question directly, but it sounds like you're talking about your own packages?
      - structural 11y ago
        Yes

ColinDabritz 11y ago

PPA = Personal Package Archive As someone who is unfamiliar with this term, can someone please summarize what it means? What makes it appealing? Thank you in advance.

jameskilton 11y ago
PPAs are how people build custom packages for Ubuntu, most often to support newer versions of software over what's available in the official package list. 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.
- fideloper 11y ago
  Typical use cases for me our to get the latest stable Nginx, PHP, HAProxy and similar popular packages without having to upgrade to a non-LTS release of Ubuntu. This would be really interesting to see on Debian!
  - stephenr 11y ago
    These types of things are already available (and I would wager much more stable than the type of thing found in PPA's) through third-party repositories like http://Dotdeb.org http://Dotdeb.org 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.
    - reubenmorais 11y ago
      PPA support would just make it easier and safer to add repositories like http://dotdeb.org http://dotdeb.org to your setup. I don't see how PPAs are any worse than manually adding entries to your sources.list file. They're almost the same thing, except the former a bit more automated.

nextos 11y ago

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.

sp332 11y ago
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.
- nextos 11y ago
  I agree, but I see them as a patch to get something that could be more cleanly achieved with a transactional packaging system.
  - organsnyder 11y ago
    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).
    - marcosdumay 11y ago

na85 11y ago

Rather upset to see Ubuntu moving away from Upstart.

pekk 11y ago
That happened shortly after the infamous Debian vote
- kleiba 11y ago
  Care to elaborate (on both, i.e., what's the upstart issue and how a Debian vote relates to it)? It seems I missed all of that, but would be grateful to learn more.
  - notatoad 11y ago
    Ubuntu created upstart around the same time systemd was created, both meant to replace the classic init system. Debian voted to adopt systemd as their new init system instead of upstart, and so now ubuntu, because of it's debian dependencies, will be dropping upstart and moving to systemd as well.
    - kleiba 11y ago
      Ta!
    - rlpb 11y ago
      > Ubuntu created upstart around the same time systemd was created, both meant to replace the classic init system. Upstart predates systemd by over four years. I just checked the initial release dates on Wikipedia to confirm. https://en.wikipedia.org/wiki/Upstart https://en.wikipedia.org/wiki/Upstart [August 24, 2006] vs. https://en.wikipedia.org/wiki/Systemd https://en.wikipedia.org/wiki/Systemd [30 March 2010]
  - tobik 11y ago
    Here is the relevant HN thread with some discussion about it: https://news.ycombinator.com/item?id=7203364 https://news.ycombinator.com/item?id=7203364

yarrel 11y ago

PPAs as they stand are an antipattern. If Debian brings some order to the chaos of unsupported, incompatible and duplicated PPA repos then that would be a win on balance. But if they just bring that chaos to Debian then it certainly won't.

shmerl 11y ago

How are PPAs different from current unofficial Debian repositories?

lukaslalinsky 11y ago
The general idea of PPAs is that they are "personal". You don't need to set up anything to create your own repository. Just build the package, upload it to the PPA and you have a fully working APT repository.
- samuellb 11y ago
  You don't even have to build the package. You just create a source package and upload it with "dput" or similar. Then the PPA servers will build your package for multiple architectures (usually x86 and x86_64, but a Debian PPA might build for all Debian architectures, which are many more). It is also possible to build for multiple versions easily by changing the target distribution in the changelog file. 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.

chriswarbo 11y ago

I never understood PPAs. Ever since /etc/apt/sources.list was split up into /etc/apt/sources.d, we've been able to manage repositories using files. Since we already manage the rest of our system files with packages, why not do the same for repos? Dump a sources.d entry, and possibly a GPG key, into a .deb package and give that to users, rather than instructions on how to enter non-standard URLs into a vendor-specific GUI. In fact, I wrote tools to do this many years ago: https://gitorious.org/debian-repo-packager https://gitorious.org/debian-repo-packager creates packages for a bunch of repos, including PPAs http://chriswarbo.net/git/service-packs.git 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.

alphapapa 11y ago
That's a sensible way. But consider the steps involved: 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.
- chriswarbo 11y ago
  > 1. Download deb package. > 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.