On Mon, Jul 17, 2017 at 09:48:46AM +0100, Daniel P. Berrange wrote: > On Sat, Jul 15, 2017 at 05:17:44PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Jul 14, 2017 at 03:42:15PM +0100, Daniel P. Berrange wrote: > > > On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote: > > > > On Mon, 2017-07-10 at 00:46 +0200, Kevin Kofler wrote: > > > > > Jaroslav Reznik wrote: > > > > > > = System Wide Change: Graphical Applications as Flatpaks = > > > > > > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Fl > > > > > > atpaks > > > > > > > > > > > > Change owner(s): > > > > > > * Owen Taylor <otaylor@xxxxxxxxxx> > > > > > > > > > > This change is leaving several questions unanswered: > > > > > > > > > > * As I understand it, those Flatpaks are going to be built from RPMs. > > > > > Is the intent to ship both the original RPMs and the Flatpak or only > > > > > the Flatpak (or is this going to depend on the individual package)? > > > > > And if the former, are the shipped RPMs going to be the FHS-compliant > > > > > version or the one relocated into Flatpak's proprietary prefix? > > > > > > > > The rebuilt RPMs are really only interesting within Flatpaks - they > > > > will be available for download from Koji, but there would be no reason > > > > for a user to do so. > > > > > > > > As for standard application RPMs, it's really going to be something > > > > we figure out over time. My vision is something like: > > > > > > > > F27: packagers are *able* to create Flatpaks of their application. > > > > They must also maintain standard RPMs. > > > > > > > > F28: packagers (of graphical applications) are *encouraged* to create > > > > Flatpaks of their applications along side standard RPM packaging. > > > > They *may* drop the standard RPM packaging if there is good > > > > reason to. > > > > > > > > F29: packagers (of graphical applications) must create Flatpaks of > > > > their applications if possible. They *may* keep standard RPM > > > > packaging. > > > > > > > > But this is really highly dependent on how modularity work happens more > > > > widely in Fedora. "standard RPM packaging" assumes we still have > > > > a F<N> tag in Koji where everything is built together with common > > > > coordinated dependencies. > > > > > > If I look at this from my POV as the upstream maintainer of a graphical > > > application wishing to make it widely available to users of many distros. > > > The question is whether it is beneficial for me to join Fedora packaging > > > world to package my app, or whether to package it standalone as a flatpak > > > and never get involved in Fedora at all. > > > > > > With the proposed F27 rule here, I would have less work todo if I just > > > built my app as a flatpak, as I can avoid creating RPMs and just build > > > a single flatpak that should work on all distros. IOW by mandating > > > continued creation of RPMs, alongside flatpaks, we would be discouraging > > > people from becoming Fedora maintainers. > > > > > > Thus could suggest more flexibility - require continued maint of RPMs > > > for *existing* applications in Fedora only, to give some grace period > > > where we figure out how to provide a seemless upgrade path for people > > > who have an existing RPM installed to magically replace it with flatpak. > > > Anyone wishing to package a *new* application in F27, however, should be > > > able to straight to flatpaks only as there's no upgrade path issue to > > > worry about. > > > > > > This would encourage upstream app maintainers to join Fedora to make > > > use of the review, build & distribution mechanisms for flatpaks, without > > > forcing them todo extra work to create RPMs too. > > > > This depends on how exactly flatpacks are built: > > - if first an rpm is built, and then flatpack is built out of rpms, > > it's strictly more work (although there are benefits to users of installing > > using flatpacks over plain rpms, so it's an actual benefit for users > > and hence not pointless). > > > > - if one is building a _leaf_ application, and all deps are available as > > rpms, then the packager doesn't need to follow the strict rpm rules, > > and if they only build a flatpack without the intermediate rpm, > > some work is saved. > > > > - if one is building an application that anything else depends on, things > > get more complicated. > > (Let's take inkscape as an example: it's a end-user graphical application, > > but it has command-line mode where it converts svgs to pngs and such, > > so it might be used e.g. when generating documentation or in %check > > for another package.) > > > > If inkscape is still available as rpm, it can be used as a dep in building > > other rpms. If however inkscape suddenly becomes available only as a flatpack, > > how does that work? Do we allow rpms to specify BuildRequires: inkscape.flatpack, > > and koji will install it and make the application available? > > Even if technically possible in the future, I don't think it's > > something we'd want to commit to right now. > > Yeah, that last point is the real difficult issue, it forces you to keep > the RPM in parallel with the flatpak, unless we were to either change > RPM (yuk), or find a way to auto-generate a RPM wrapper around the flatpak > to pull in it contents. I have to say that I find the opposite approach (find a way to auto-generate a flatpak from RPM) much more appetizing. It's much more efficient (flatpaks are often two orders of magnitude bigger, so pulling in any number of flatpaks as build deps would have a noticeable deleterious effect on build speed, because buildroot generation is the slowest step for many packages), and much more aligned with existing infrastructure (iiuc, that's how some flatpaks are built today, so it's almost there, except for the "automatic" part), and makes more sense in general (build large things out of small, instead of wrapping a big thing to make it pretend to be small.) > > So in the end, flatpacks as an *additional* distribution mechanism > > sound fine. But if they become the *only* distribution mechanism, we > > risk that the whole ecosystem of packages which can all be used to > > build one another falls apart. > > I guess one key question is how often the Inkscape situation arises where > a graphical application can be considered both a leaf node, and a dependancy > for other arbitrary app. At lower levels of the stack, we know that the dependency graph is effectively almost strongly connected (c.f. the efforts of the Base Working Group and Harald Hoyer's graphs, https://harald.fedorapeople.org/base-build-fc26-20170125/base-build.svg). At the higher level, I don't think anybody has made much research, but I expect that a) there's much more leaf nodes, b) there's still enough deps on the graphical packages to require rpms. For inkscape, eog, firefox: $ dnf repoquery --disablerepo=\* --enablerepo=fedora-source --arch=src --whatrequires inkscape bacula-docs-0:7.4.7-1.fc26.src djvulibre-0:3.5.27-2.fc26.src gnome-colors-icon-theme-0:5.5.1-10.fc26.src gnome-documents-0:3.24.2-1.fc26.src pacemaker-0:1.1.17-0.1.rc4.fc26.src tuxanci-0:0.21.0-4.fc26.src vfrnav-0:20160429-7.fc26.src $ ... --whatrequires eog (nothing) $ ... --whatrequires firefox freewrl Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
