Alexander Larsson píše v Čt 16. 06. 2016 v 21:11 +0200: > On Thu, 2016-06-16 at 14:24 -0400, Ben Rosser wrote: > > On Thu, Jun 16, 2016 at 1:30 PM, Matthew Miller <mattdm@fedoraproje > > ct.org> wrote: > > > On Thu, Jun 16, 2016 at 01:12:07PM -0400, Ben Rosser wrote: > > > > ship pip, npm, etc? Where I become uncomfortable, and the > > > reason I chimed > > > > in on this thread initially, is with the idea that these new > > > containerized > > > > packaging systems are in some way *superior* to traditional > > > packaging. Or > > > > at least that's what I read between the lines of the proposal > > > to allow > > > > upstreams to ask for their flatpaks or whatever to be shipped > > > in place of > > > > RPMs. > > > > > > I think that once the full sandboxing / portal system is in > > > place, > > > there _will_ be a tangible reason to prefer Flatpak. > > > > > > > > > > Well, assuming that turns out to be the case, should our packaging > > guidelines eventually become "do not make RPM packages of end-user > > applications but instead make a downstream flatpak package"? I'd > > probably have mixed feelings about this, too, and it's not what the > > Workstation proposal suggests at the moment, either, but it seems > > to be where we're eventually leading here. > > > > Or, we could have tooling to turn a RPM into a flatpak, perhaps (I > > know there's a script to do this for AppImages), and use this in > > our build infrastructure? > > For atomic workstation, this is the goal. We even need that, because > in that setup the OS (/usr) would be a read-only image (based on > rpms), so we could not install new rpms. Instead we'd take our > existing rpms and create flatpaks from them. It's useful for upstream projects, too. For instance, we decided not to include Java in the upstream LibreOffice flatpak because it's a big burden to maintain (checking for updates, rebuilding,...) the whole Java stack because of minor functionality. But then it's not a drop-in replacement for current official installation files and it will probably be required eventually. Then it's probably best to hook the flatpak building to some distribution, take the bundled components from RPMs and let the distro maintainers do the maintenance. An update of a distro RPM triggers an automated rebuild of the flatpak. Packages are IMHO far from being obsoleted. Jiri
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
