On 20 November 2015 at 22:54, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > Also, I'm not sure the Linux desktop has much of a future unless the > situation improves sooner. The number of Linux desktop users I know is > dwindling as they convert to Mac. Programming conferences, even where > open source software plays a big part, are now a sea of Macbooks. We > need bigger plans like sandboxing technology, but we also need something > to move the status quo forwards.
I get where you're getting at but yet-another-packaging-format is not the solution... You can write wrapper over wrapper over wrapper and all you end up with is a thousand wrappers. You didn't fix the underlying issue. Every format sucking in its own right means there's no clarity in what you should distribute as an app developer. If you're not intimately familiar with linux, your problem is "Hey, should I distribute debs? rpms? tarballs? can I not distribute binaries? do I need to let the distro handle my stuff? what's that pacman they're talking about?" -- adding another item into that particular mix is simply not useful. This is a problem that fixes itself the moment distros start converging towards a common format. Part of the issue is technical for sure, but the technical problems don't reveal themselves until after you know what the political solutions are. So deb, rpm and tar.*z are really all the same format, with differing metadata on top. This is the big item to outsiders, and it's the easiest item to converge on. Where it gets hard is "agreeing" on the resulting structure, the various etc/usr/whatever prefixes and what not. Every distro has, in their own eyes, equal claim to their own way of doing things - you can't just say "Debian is doing it right. Now we're debian."... and whatever you do decide means a massive migration for everyone else *and* you didn't really fix the problem. Smaller distros doing-their-thing could become big with just a little corporate backing and you're back to square 1. The sandboxing drive we're seeing (aka the android model) moves that problem to a different layer. You're now packaging for the layer, similarly to distro maintainers that are packaging for their layer (the distro). If you want to fix packaging, this is the only non-whackamole route. But it's not enough to do that in a vacuum, you also have to have a global vision of each distribution's problems, solutions and reasonings which is a far bigger task, hence why the technical aspect is insignificant in comparison. What we're seeing with Limba (what Jasper linked) for example is a saner approach. It's still just one piece of the puzzle, but it understands that 1. The larger problem is metadata and 2. A solution in a vacuum is not a solution. J. Leclanche _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg