Flatpaks for Fedora 27
Flatpaks for Fedora 27
Posted Jul 26, 2017 20:55 UTC (Wed) by drag (guest, #31333)In reply to: Flatpaks for Fedora 27 by jdulaney
Parent article: Flatpaks for Fedora 27
Fedora isn't the only distribution out there that cares about high quality packaging. If flatpaks gain acceptance then for desktop applications the efforts of different distributions can be combined. So instead of just Fedora improving the quality of packaging in Fedora you have Debian, Ubuntu, Arch, Suse, and other packagers all working on improving the quality of packaging for Fedora users.
Posted Jul 26, 2017 23:38 UTC (Wed)
by pizza (subscriber, #46)
[Link] (18 responses)
I share jdulaney's expectations of an outcome of utter rubbish; you'll end up with what you have today, only instead of a tarball of unmaintained everything that you plop somewhere in /opt, you'll instead have the same unmaintained everything wrapped inside a fancier container.
Posted Jul 27, 2017 1:57 UTC (Thu)
by drag (guest, #31333)
[Link] (12 responses)
Why is it such a forgone conclusion that the people packaging the software now will have nothing to do with packaging the software in the future? You think that people working in Fedora or other distributions that package software will have no interest or ability whatsoever with working with upstream authors to increase the quality and creating acceptable guidelines?
I think it's silly notion that the only possible way that Linux distributions can have quality packages for users is that they must insert themselves as blockers and control access to software binaries in such a way as to prevent end users to ever come into contact with anything directly produced by software authors.
Posted Jul 27, 2017 3:39 UTC (Thu)
by pizza (subscriber, #46)
[Link] (11 responses)
The packagers for Fedora, Debian, or whatever have *always* wanted to work more closely with upstream authors.
Remember, the goal here isn't for Flatpak to be used by only a single distro -- there's no advantage to that versus the distro's native packaging. Instead, this is intended to be sorta universal. But then you'll run right back into the problem where the runtimes will either be completely over- or under-specified, both leading to the inevitable conclusion where you'll have to bundle the world with your "universal" flatpak in order for it to work everywhere.
Posted Jul 27, 2017 8:59 UTC (Thu)
by mjthayer (guest, #39183)
[Link]
For us though it should also make it easier to do higher quality upstream packaging by reducing the number of different environments we have to target, and by providing an environment which should be both more friendly to out-of-distribution packagers and to distribution people wanting to work with us.
Posted Jul 28, 2017 13:38 UTC (Fri)
by otaylor (subscriber, #4190)
[Link] (9 responses)
Runtimes aren't specifications, they are actual binary bits. If you build and test your application against version 1.6 of the org.freedesktop.Platform or version 27 of the org.fedoraproject.Platform runtime, then other than bug fixes and security updates, you have tested with the exact same libraries that your users will be running with - whether they are on Fedora 27, or Fedora 28, or Debian. So there's never a need to bundle a library because you are worried it won't work the same everywhere. (You might need to bundle a library because it isn't in the runtime you are building against, or because you need a newer version.)
The expectation is that users will have a small handful of runtimes on their systems - the increase in disk space is a tradeoff to get the benefit of reliable cross-distribution and cross-distribution-version binaries. Ending up with dozens of runtimes in use, or not having clear recommendations to application developers about how to select a well-maintained runtime - those would be failures of the Flatpak ecosystem, and are things we are working to avoid.
Posted Jul 28, 2017 14:16 UTC (Fri)
by pizza (subscriber, #46)
[Link] (7 responses)
The reality is that users will have a *large* number of runtimes on their systems, including multiple versions of individual runtimes.
> Ending up with dozens of runtimes in use, or not having clear recommendations to application developers about how to select a well-maintained runtime - those would be failures of the Flatpak ecosystem, and are things we are working to avoid.
It won't be a failure of the Flatpak ecosystem per se, but an acknowledgment of the reality that the overwhelming majority application developers are going to do the bare minimum of effort to get their software packaged and delivered. Which means they'll stick to the original runtime set they started with. This will only get worse as proprietary vendors start doing this too -- and you can bet they'll compound ancient (and long-since-unmaintained) runtimes by bundling plenty of other libraries too.
I don't intend to come off as cynical here, and I really want to be shown to be wrong, but after twenty years of dealing with this crap, I can't see how technical wizardry is going to solve fundamental problem of people putting minimal (if any) thought/effort into longer-term maintainability.
Posted Jul 28, 2017 15:44 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Flatpak can address it to a good extend by making the right thing to do is easy and obvious. This includes the tools but also the documentation. The worst case scenario of multiple runtimes is still going to be better than a typical third party RPM repo (Chrome relying on redhat-lsb instead of redhat-lsb-core thereby installing multiple needless dependencies.. Skype RPM which is missing a lot of dependencies etc)
Posted Jul 28, 2017 17:28 UTC (Fri)
by zlynx (guest, #2285)
[Link] (4 responses)
Even this year I've installed packages that still use the 2005 runtime because of XP support. Also they probably don't wish to pay their developers to update ancient C++ code to 2017 standards.
Yes, open source software projects hate having to fix old bugs revealed by LTO optimizing compilers, or new versions of malloc/new and memcpy in the libraries. But this does push their software forward in a way that proprietary software doesn't get. Does anyone want code that only builds with an ancient compiler and library set from 15 years ago?
Posted Jul 28, 2017 19:15 UTC (Fri)
by excors (subscriber, #95769)
[Link]
I think even the latest version of Visual Studio (and its associated CRT) has XP runtime support - you just have to choose to compile with an _xp version of the 'Platform Toolset', and then it should work fine for users on XP.
(You can't run VS itself on XP, but any developers who are still using XP are insane.)
One possible reason for sticking with an ancient version of VS is that you can't safely mix libraries built with different versions (unless they're DLLs that are very careful about their interfaces). If you've got a third-party binary-only library that was built with VS2005 and is impossible to update, or if you've got hundreds of open source libraries that you're just too lazy to recompile (because you've got to load each one into VS individually, upgrade the project file, fix all the build failures, manually copy the build output into the right place, etc), you might want to stick with VS2005 forever. Open source projects seem pretty good at avoiding that situation, by only depending on open source libraries and by having build scripts that make it trivial to rebuild everything with the latest toolchain.
(I suspect some people are also tied to an ancient version of VS by IDE plugins that don't support anything newer (at least without an expensive licence renewal). And some people stuck with VC6 for like a decade just because they thought the new IDE was ugly and slow.)
Posted Jul 28, 2017 22:17 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (1 responses)
> they probably don't wish to pay their developers to update ancient C++ code to 2017 standards.
> Does anyone want code that only builds with an ancient compiler and library set from 15 years ago?
Just highlighting that not all useful code bases have dedicated on-going maintenance budgets or volunteers willing to maintain distro packages of unmaintained software, so having a somewhat reasonable way to reliably run old code is as problem that MS had to solve for Windows (which has orders of magnitude more software that is expected to run), so its not surprising that other solutions end up in the same general shape with how runtimes are defined.
Posted Jul 28, 2017 23:14 UTC (Fri)
by pizza (subscriber, #46)
[Link]
Yeah, instead we'll have a growing number of flatpaks of unmaintained software that only runs (and/or if source is available, compiles only) on ancient, unmaintained runtimes. Because why put forth any effort into something that still "works"?
Also, let's not forget that while being able to reliably run old code was surely a boon for Microsoft, it also became a considerable millstone around their necks.
Posted Aug 3, 2017 9:18 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
YES!
A program I would love to get running again is WordPerfect - which relies on libc5 ...
(I know I go on about it, but the reality is I almost never use office software nowadays, so it's not worth the effort getting it working. But if I could get it running it would take over "just like that" - replacing Word and loWriter for me in a heartbeat!)
Cheers,
Posted Aug 3, 2017 2:37 UTC (Thu)
by Garak (guest, #99377)
[Link]
Posted Aug 4, 2017 3:39 UTC (Fri)
by HelloWorld (guest, #56129)
[Link]
Posted Jul 28, 2017 13:30 UTC (Fri)
by anton (subscriber, #25547)
[Link] (4 responses)
Posted Jul 28, 2017 14:22 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
And 3rd-party packages are a second-rate option in the same way that out-of-tree kernel modules are a second-rate option. It's a fundamental property of how they're developed and delivered, and will always lag behind the mothership unless said 3rd party is sufficiently proactive.
Posted Jul 30, 2017 15:28 UTC (Sun)
by anton (subscriber, #25547)
[Link] (2 responses)
In any case, if you want the package derived from the most recent upstream release (as your "lag" criterion indicates), if you have alternative packages, you can select that (and ideally, you could tell the package management that this is your preference, and it will do it automatically for you).
Posted Jul 31, 2017 3:11 UTC (Mon)
by foom (subscriber, #14868)
[Link] (1 responses)
Posted Aug 1, 2017 10:54 UTC (Tue)
by anton (subscriber, #25547)
[Link]
Anyway, this shows the potential value of third-party packages: The packager could disable this (mis)feature without introducing the Debian-originated papersize bug.
Flatpaks for Fedora 27
Flatpaks for Fedora 27
Flatpaks for Fedora 27
But cooperation has always been a two-way street. The upstream authors that want to work with distributions generally already do so. But the rest don't want to -- and what's the point of writing yet another set of guidelines that will just be ignored anyway? (Owncloud was a particularly aggregious example that comes to mind; they actually rejected the distro packagers' suggestions and patches to make things, oh, not require manual intervention on *every* package update. Grumble..)
Flatpaks for Fedora 27
Flatpaks for Fedora 27
Flatpaks for Fedora 27
Flatpaks for Fedora 27
Flatpaks for Fedora 27
Flatpaks for Fedora 27
Flatpaks for Fedora 27
Flatpaks for Fedora 27
Flatpaks for Fedora 27
Wol
Flatpaks for Fedora 27
I don't intend to come off as cynical here, and I really want to be shown to be wrong, but after twenty years of dealing with this crap, I can't see how technical wizardry is going to solve fundamental problem of people putting minimal (if any) thought/effort into longer-term maintainability.
I think the fundamental problem here is that people talk about the issue as a fundamental problem. I think people's worldview should expand to include the nuance that one cannot overstate the variance of importance between software packages. All this top-down academic talk tries to treat 'the software development efficiency' problem as something to try and solve in one way for all software. That's wrong. As each important piece of software increases its stature of importance, different methodologies (more thought/effort) will be applied to their development. There is no 'fundamental problem' with this. What there is is an abundance of software developers and academics trying to make a name for themselves and this issue as with a few others, seem to get a lot of milage. I'd rather those folks stopped trying to fix all software at the same time, and instead focused their thought and effort on specific packages. But the realist/cynic in me knows that we will see this recurring narrative for decades. I think it's somewhat related to open source pundits that view forking, casual and otherwise as a bad thing. I think the ecosystem would benefit from a thousand fold increase in forking. Sure, like most blades of grass or baby animals, most forks will have relatively short uneventful lives. But the power of evolution comes about because most individuals don't matter that much to the big picture. What matters is enough diversity so that the better solution eventually/inevitably comes about. Nature is full of crap. The solution isn't to redesign the digestive system, it's to watch where you are stepping. If you are afraid to get your shoes dirty, you can pay the toll to stroll in some super-rich people's walled garden. In fact there are many walled gardens to choose from, and over time, the ones with the most crap will fade, while others will thrive. Of course there may also be competing products that allow you to enjoy strolls through unwalled jungles- clever safety equipment that prevents you from slipping on dog turds and being bitten by poisonous creatures. I can't say what things will look like in a hundred years, but I don't think there is really a fundamental problem here.
Flatpaks for Fedora 27
It gives the user the choice between the quality of the distribution-"improved" package, and the quality of the upstream-provided package, or the quality of some third-party-improved package. In theory, this will lead to better quality (at least in my world which contains distribution packages that are worse than what's coming from upstream, e.g. Debian's version of xpdf), but I am sure the distributions will at least arrange things to make using non-distribution-provided packages look like a second-rate option, and make it inconvenient to use them.
Flatpaks for Fedora 27
Flatpaks for Fedora 27
In cases like xpdf where the distribution introduced a bug that is not present in the upstream, and fails to fix it in the course of several years, it's very easy for a third party to provide a package that is better than the distribution package. Also, given that the distribution has made extensive changes to xpdf, it's also much easier for a third party to lag less behind upstream than the distribution does. Concerning proactivity, there is no magic that makes people more proactive just because they are distribution maintainers.
Flatpaks for Fedora 27
Flatpaks for Fedora 27
I think this is a result of the xpdf developers' stance on digital restriction management of PDFs, i.e., they consider it a feature. So "misfeature" might be more accurate than "bug".
Flatpaks for Fedora 27