Poettering: Revisiting how we put together Linux systems

Posted Sep 3, 2014 20:46 UTC (Wed) by martin.langhoff (subscriber, #61417)
In reply to: Poettering: Revisiting how we put together Linux systems by raven667
Parent article: Poettering: Revisiting how we put together Linux systems

So we expect a new role in the ecosystem: "app packagers"; and we are giving them a rather hellish test matrix. Not only every major distro LTS and cadence releases, but 3 different "base systems" for every release.

Looking at it from this perspective, things look even weirder. If application (and app stack) developers were keen on this kind of distribution, tools like Klik and ZeroInstall would be much more popular amongst app developers and users than they are today.

I honestly believe that most projects are happy to leave packaging, with all the specialized knowledge it entails about ABI changes in different distro releases, to folks on the distro side. The exceptions are very large projects, with the manpower and "ecosystem" to sustain that role. Those projects are hosting their PPA/Copr style repositories already -- but it's not that many, and you can see those repos are not that well maintained.

Poettering: Revisiting how we put together Linux systems

Posted Sep 3, 2014 21:04 UTC (Wed) by raven667 (subscriber, #5198) [Link] (2 responses)

> So we expect a new role in the ecosystem: "app packagers"; and we are giving them a rather hellish test matrix. Not only every major distro LTS and cadence releases, but 3 different "base systems" for every release.

I think the proposal is for the exact opposite, an app package will depend on exactly one runtime and will not claim to work with anything else, reducing the test matrix from all popular distros which a user might conceivably have installed to just the one type of system they built the app on in the first place.

> Klik and ZeroInstall would be much more popular

This does cover some of the same ground as those utilities, this is a discussion about how to solve this in a generic and standard way across all of the different kinds of Linux, maybe avoiding some of the pitfalls those utilities have had.

> I honestly believe that most projects are happy to leave packaging, with all the specialized knowledge it entails about ABI changes in different distro releases, to folks on the distro side.

Which is a system this proposal preserves as the distros are the ones maintaining /usr volumes, as an application developer you get to choose which /usr fits your needs and can rely on the end user being able to easily get a copy of that /usr, supported by its distributor, when they want to run your application, without disturbing the rest of their system preferences.

Poettering: Revisiting how we put together Linux systems

Posted Sep 3, 2014 21:17 UTC (Wed) by martin.langhoff (subscriber, #61417) [Link] (1 responses)

@raven677, can you clarify whether you mean

a - that each bundle will match only one "base OS runtime", but that you expect app packagers to produce one bundle for each popular "base OS runtime"? In this case the test matrix is 1:1 for each bundle, but large for the app packaging team...

b - that each app dev team will publish _one_ bundle, matched to one "base OS runtime". In this scenario, it is the "end user"/sysadmin that might be in a situation of having to install and run a particular base OS runtime because the app bundle demands it.

Or perhaps both depending on manpower. I don't like an ecosystem that spans the gamut between these two dynamics.

Most app projects are under-resourced, so I suspect case "b" will be the most common case. So if on my desktop I'm running a dozen apps, they might in turn each be coupled to a specific OS runtime, so perhaps I'd be running bits and pieces of 6 OS runtimes.

Poettering: Revisiting how we put together Linux systems

Posted Sep 3, 2014 21:36 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Yes, the proposal describes situation B in your listing, situation A is the current status quo where apps are already packaged separately for each base OS runtime and few app packages are maintained by their upstreams because dealing with the quirks of N possible base OS runtimes is too difficult, the ones that do their own app packages in the status quo tend to have to bundle a lot of libraries because there is no ABI discipline between base OS runtimes.

So yes, you might have 6 different base OS /usr runtimes installed to run 6 different apps although it seems clear that there will be a lot of pressure to standardize on just a few /usr runtimes in each use case (Desktop, Server, Phone, Tablet, IVI, Network appliance, other embedded, etc.) and since this reduces the friction of maintaining different /usr spaces (no re-install or booting of VMs) it makes the process of shaking out what developers and users really want from /usr smoother.

Maybe this could lead to a resurgence of LSB, defining the ABI for an entire /usr for applications to target rather than a uselessly small subset. By changing where the pain points are for supporting applications a very different marketplace could stably emerge.