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 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".
Looks neat. My intranet is completely airgapped. Is your enterprise offering self-hosted? "Works with your infrastructure" on your webpage is very ambiguous.
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.
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.
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.
In an ideal world, we'd only be getting packages built on integration test passes, and automatically pushed from CI. I've got that for some cases, but it's still a manual push process for others.
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.
The way I use dpkg-scanpackages is to have a single, central repo machine, with independent repositories for different projects. Publishing a .deb is the same for any project - scp, then ssh and run make in that project's directory. I have a very short shell script called publish-deb which does exactly that.
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.
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]
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.
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.
