On 07/10/2017 09:31 PM, Owen Taylor wrote: > > 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. Perfectly fine :) Adds an additional, but optional, way of distribution. I don't like Flatpak, but as long as I'm not forced and RPM is the standard packaging, I just ignore it ;) > > 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. So we could end up in a situation where neither Flatpak nor RPM provide a complete package/application set? Would be bad… and also inconsistent. Also: What additional work does Flatpak require for me as a packager? I read something about automated builds, but then we would not need this discussion and could create both worlds. As I have limited time, I'll provide my packages in one consistent way, not multiple ways. As I have both graphical applications and other stuff, that will be RPM for sure. > > F29: packagers (of graphical applications) must create Flatpaks of > their applications if possible. They *may* keep standard RPM > packaging. I hope we will *never* reach that point, if we reach it, I have to move to another Linux distribution which follows the rules of construction I prefer. As a packager I know how much many upstreams love bundling (and not updating bundled libs), IMHO Flatpak (in general) encourages them to do that (yes I know, they can do also for RPM, but Flatpak makes it easy). And outdated libraries are a high security risk (heartbleed etc. ;)) and sandboxing can never save you from all possible impacts. Sandboxing is an *additional* and as said in some other mail *orthogonal* mechanism to clean packaging. I feel we lose many advantages over operating systems like Windows if we open that door and continue that way… > > 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. > > The Change proposal, in any case is really only about enabling this as > an something that packagers may opt into if they want to. That said, for the optional availability of flatpak for packagers: I'm perfectly fine with that, I'll just ignore it for my stuff. But if there will be proposals which will change Fedora in a way that I think is wrong, I'll be back to discuss them ;) Also I know from IRC that there are more packagers thinking the same way. Greetings, Christian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
