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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
