> Linux distribution developer tells application and system developers that packaging is a solved problem, as long as everyone uses the same OS, distribution, tools, and becomes a distro packager.
There is no such thing as Linux. There is Redhat Enterprise Linux, Ubuntu Linux, OpenSUSE Linux, Debian Linux, ArchLinux, etc.. These are systems with a loose set of tools in common but differ to the point of absurdity in organization, structure, availabile software, and capabilities.
Supporting multiple distributions should be viewed as supporting multiple platforms. You can either port your software or bundle all your dependencies, all the way down to libc if you want.
> making sure that the overall OS fits into a fairly specific view of how computer systems should work
Which is another name for 'software is incredibly complex and conventions are needed if you want to stay sane'.
Quick, where do web applications go? /srv/myapp, /opt/myapp, /usr/share/webapps/myapp, /usr/share/myapp, /var/www/myapp, /var/myapp/, /myapp, /usr/local/myapp? If you answered all of this above you've used 3rd party software on a Linux system. Where do you think the logs for all those locations wind up?
Packaging is the art of beating software into submission so that it can actually be managed, secured, audited, and monitored.
> You're still supposed to go ask your sysadmin for an application to be available, and you’re still supposed to give your application to the sysadmin so that they can deploy it — with or without modifications.
This is PaaS which isn't mandatory but highly suggested when dealing with teams of developers. You write the code until it works, we deal with making that new library you want that was released two weeks ago work, deal with the licensing of your APIs, libraries, drivers, and tooling, and integrating it into your CI/CD pipeline. You just write the code.
> to convince the developers of...
Because that's not how it works, we take your source distribution model, pip, bundle, npm (i.e upstream) and turn them into packages. There's no convincing to do because they're not in conflict.
> The issue is not the 'managed by somebody' part; the issue is the inevitable intermediary between an application developer and an application user.
This is what it's really about. Devs don't understand what ops people actually do and just see them as a team that slows them down and tells them no a lot.
> developers are heavily based on the concept of a core set of OS services; a parallel installable blocks of system dependencies shipped and retired by the OS vendor
Otherwise known as a the packages your distribution ships.
> How did foo get into the repository?
Because a distribution vendor thought your software was useful, packaged it for distribution, and put it in their repository. At this point it is NO LONGER your software or your responsibility. The vendor has adopted this package and committed ensuring that it works and is maintained. People with problems should (and do) complain to them rather than you.
> How can you host a repository, if you can’t, or don’t want to host it on somebody else’s infrastructure?
https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
You make a repository and host it on your infrastructure. I promise it will be the easiest web service you've ever configured.
> What happens when you have to deal with a bajillion, slightly conflicting, ever changing policies?
Depends, if you're distributing it yourself then you treat it like cross platform work. If distributions are packaging them for you, then you sit back and let them do it. If your IT dept is deploying your software then you let them handle it.
> How do you keep your work up to date for everyone, and every combination?
You push an update (i.e copy a file) to your repository, then people download and install it. Again, if you're opting for either distro maintainers or IT dept you just publish your code and let them deal with it.
> What happens if you cannot give out the keys to your application to everyone, even if the application itself may be free software?
You distribute the software (myapp) and (myapp-license or myapp-api-keys) in a separate package and mark the keys as a dependency.
> Scalability is the problem; too many intermediaries, too many gatekeepers.
There aren't any gatekeepers. There are people are doing work for you. You are totally in control. You (or your org) can opt to have some of that work done for you. You can't pretend that it doesn't need to be done at all.