Hi all
My name is Joël Krähemann. I maintain Advanced Gtk+ Sequencer and I'd like to provide it in fedora. Linux is my OS of choice since 2001. Along the time I have used many distributions like debian, linux from scratch, SUSE, fedora and a few others.
Prior I did an RPM spec provided on:
https://sourceforge.net/projects/ags/files/fedora/
Note the project is mainly hosted by GNU Savannah.
The domain http://gsequencer.org is forwarded to it. Current stable version of GSequencer is 0.7.113 and I'm working on version 1.0. The branch 0.7.x only gets bug-fixes or features back-ported I'd really like to see there.
Next goals are doing remote bindings and lv2 UI support as well extending MIDI support. Further I'd like to accelerate loading Lv2 plugins the current code doing XPath lookup with RDF turtle converted XML is slow for certain plugins. But you are able to blacklist if you wish.
Bests, Joël
On Thu, 8 Dec 2016 15:21:21 +0100, Joël Krähemann wrote:
My name is Joël Krähemann. I maintain Advanced Gtk+ Sequencer and I'd like to provide it in fedora. Linux is my OS of choice since 2001. Along the time I have used many distributions like debian, linux from scratch, SUSE, fedora and a few others.
Hello!
Here find some helpful links about the Fedora Packager and their processes:
* https://fedoraproject.org/wiki/Join_the_package_collection_maintainers * https://fedoraproject.org/wiki/Category:Package_Maintainers * https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group * https://fedoraproject.org/wiki/Package_Review_Process
* category overview: https://fedoraproject.org/wiki/Category:Package_Maintainers
On Thu, Dec 08, 2016 at 05:13:24PM +0100, Michael Schwendt wrote:
On Thu, 8 Dec 2016 15:21:21 +0100, Joël Krähemann wrote:
My name is Joël Krähemann. I maintain Advanced Gtk+ Sequencer and I'd like to provide it in fedora. Linux is my OS of choice since 2001. Along the time I have used many distributions like debian, linux from scratch, SUSE, fedora and a few others.
Hello!
Here find some helpful links about the Fedora Packager and their processes:
In particular, you should open a Review request for gsequencer as the next step.
From a quick view at the spec file: Source0 should be a full URL
'-n gsequencer' is a noop, just drop it for readability. Similarly, %setup -q -n %{name}-%{version} → %setup -q or oven just %autosetup.
In %files: %{_libdir}/gsequencer/* → %{_libdir}/gsequencer (you need to "own" the directory too). Similarly in %{_datadir}, if you run rpmlint I'm pretty sure it'll complain about unowned directories.
In general, it's better to put each Requires/BuildRequires item on it's own line. Diffs looks better and it's easier to spot mistakes.
No dots at the end of Summary.
Some of the explicit dependencies, e.g. Requires: libags, are most likely uneeded — rpm generates dependencies on libraries automatically.
Also, I'm not sure you need so many subpackages: it's not Debian where every teeny-tiny library needs a separate subpackage. In particular, you can at least merge all the -devel subpackages into one.
But the package looks nice in general. Should not be an issue to get it accepted.
Zbyszek
Hi all
Just modified the gsequencer.spec file. Now, it should be more the fedora way.
https://sourceforge.net/projects/ags/files/fedora/
Additionally, I uploaded the srpm and rpm packages built.
* gsequencer * gsequencer-devel * gsequencer-devel-docs * gsequencer-debuginfo
Bests, Joël
On Thu, Dec 8, 2016 at 6:30 PM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Thu, Dec 08, 2016 at 05:13:24PM +0100, Michael Schwendt wrote:
On Thu, 8 Dec 2016 15:21:21 +0100, Joël Krähemann wrote:
My name is Joël Krähemann. I maintain Advanced Gtk+ Sequencer and I'd like to provide it in fedora. Linux is my OS of choice since 2001. Along the time I have used many distributions like debian, linux from scratch, SUSE, fedora and a few others.
Hello!
Here find some helpful links about the Fedora Packager and their processes:
In particular, you should open a Review request for gsequencer as the next step.
From a quick view at the spec file: Source0 should be a full URL
'-n gsequencer' is a noop, just drop it for readability. Similarly, %setup -q -n %{name}-%{version} → %setup -q or oven just %autosetup.
In %files: %{_libdir}/gsequencer/* → %{_libdir}/gsequencer (you need to "own" the directory too). Similarly in %{_datadir}, if you run rpmlint I'm pretty sure it'll complain about unowned directories.
In general, it's better to put each Requires/BuildRequires item on it's own line. Diffs looks better and it's easier to spot mistakes.
No dots at the end of Summary.
Some of the explicit dependencies, e.g. Requires: libags, are most likely uneeded — rpm generates dependencies on libraries automatically.
Also, I'm not sure you need so many subpackages: it's not Debian where every teeny-tiny library needs a separate subpackage. In particular, you can at least merge all the -devel subpackages into one.
But the package looks nice in general. Should not be an issue to get it accepted.
Zbyszek
On Fri, 9 Dec 2016 21:57:07 +0100, Joël Krähemann wrote:
Hi all
Just modified the gsequencer.spec file. Now, it should be more the fedora way.
https://sourceforge.net/projects/ags/files/fedora/
Additionally, I uploaded the srpm and rpm packages built.
- gsequencer
- gsequencer-devel
- gsequencer-devel-docs
- gsequencer-debuginfo
So, do you want to offer it for official package review or not? It still contains a lot of packaging mistakes _not_ specific to Fedora.
Hi Michael
I'm not sure of what packaging mistakes you are talking. I just updated the spec file and removed the requires field.
But yes, I'd like to give it for review now.
Bests, Joël
On Fri, Dec 9, 2016 at 10:04 PM, Michael Schwendt mschwendt@gmail.com wrote:
On Fri, 9 Dec 2016 21:57:07 +0100, Joël Krähemann wrote:
Hi all
Just modified the gsequencer.spec file. Now, it should be more the fedora way.
https://sourceforge.net/projects/ags/files/fedora/
Additionally, I uploaded the srpm and rpm packages built.
- gsequencer
- gsequencer-devel
- gsequencer-devel-docs
- gsequencer-debuginfo
So, do you want to offer it for official package review or not? It still contains a lot of packaging mistakes _not_ specific to Fedora. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Hi all
For your information
http://koji.fedoraproject.org/koji/taskinfo?taskID=16809691 https://copr.fedorainfracloud.org/coprs/jkraehemann/gsequencer/
Bests, Joël
On Fri, Dec 9, 2016 at 10:15 PM, Joël Krähemann jkraehemann@gmail.com wrote:
Hi Michael
I'm not sure of what packaging mistakes you are talking. I just updated the spec file and removed the requires field.
But yes, I'd like to give it for review now.
Bests, Joël
On Fri, Dec 9, 2016 at 10:04 PM, Michael Schwendt mschwendt@gmail.com wrote:
On Fri, 9 Dec 2016 21:57:07 +0100, Joël Krähemann wrote:
Hi all
Just modified the gsequencer.spec file. Now, it should be more the fedora way.
https://sourceforge.net/projects/ags/files/fedora/
Additionally, I uploaded the srpm and rpm packages built.
- gsequencer
- gsequencer-devel
- gsequencer-devel-docs
- gsequencer-debuginfo
So, do you want to offer it for official package review or not? It still contains a lot of packaging mistakes _not_ specific to Fedora. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Fri, Dec 09, 2016 at 09:57:07PM +0100, Joël Krähemann wrote:
Hi all
Just modified the gsequencer.spec file. Now, it should be more the fedora way.
https://sourceforge.net/projects/ags/files/fedora/
Additionally, I uploaded the srpm and rpm packages built.
- gsequencer
- gsequencer-devel
- gsequencer-devel-docs
This should be gsequencer-doc (note no "s").
- gsequencer-debuginfo
On Thu, Dec 08, 2016 at 05:13:24PM +0100, Michael Schwendt wrote:
On Thu, 8 Dec 2016 15:21:21 +0100, Joël Krähemann wrote:
My name is Joël Krähemann. I maintain Advanced Gtk+ Sequencer and I'd like to provide it in fedora. Linux is my OS of choice since 2001. Along the time I have used many distributions like debian, linux from scratch, SUSE, fedora and a few others.
Hello!
Here find some helpful links about the Fedora Packager and their processes:
In particular, you should open a Review request for gsequencer as the next step.
See this last URL. It describes the steps to open a Review request.
Zbyszek
On Sat, 10 Dec 2016 04:18:44 +0000, Zbigniew Jędrzejewski-Szmek wrote:
Here find some helpful links about the Fedora Packager and their processes:
In particular, you should open a Review request for gsequencer as the next step.
See this last URL. It describes the steps to open a Review request.
Well, the first link is to a step-by-step guide that also includes one section about creating a review request, and a link to the Package Review Process description is included in there, too.
On Sat, Dec 10, 2016 at 03:58:41PM +0100, Michael Schwendt wrote:
On Sat, 10 Dec 2016 04:18:44 +0000, Zbigniew Jędrzejewski-Szmek wrote:
Here find some helpful links about the Fedora Packager and their processes:
In particular, you should open a Review request for gsequencer as the next step.
See this last URL. It describes the steps to open a Review request.
Well, the first link is to a step-by-step guide that also includes one section about creating a review request, and a link to the Package Review Process description is included in there, too.
Sure. But I thought it would be beneficial to point the OP directly to that section, since discussion was happening here and on IRC, and a review request is more appropriate for that.
Zbyszek
Hey Joel,
----- Original Message -----
Hi all
My name is Joël Krähemann. I maintain Advanced Gtk+ Sequencer and I'd like to provide it in fedora. Linux is my OS of choice since 2001. Along the time I have used many distributions like debian, linux from scratch, SUSE, fedora and a few others.
Prior I did an RPM spec provided on:
https://sourceforge.net/projects/ags/files/fedora/
Note the project is mainly hosted by GNU Savannah.
The domain http://gsequencer.org is forwarded to it. Current stable version of GSequencer is 0.7.113 and I'm working on version 1.0. The branch 0.7.x only gets bug-fixes or features back-ported I'd really like to see there.
Next goals are doing remote bindings and lv2 UI support as well extending MIDI support. Further I'd like to accelerate loading Lv2 plugins the current code doing XPath lookup with RDF turtle converted XML is slow for certain plugins. But you are able to blacklist if you wish.
I would advise you to look into packaging your application using Flatpak: http://flatpak.org/ so that you can package your application for both Fedora, and every other distribution out there that has Flatpak available to it.
Cheers
Bastien Nocera wrote:
I would advise you to look into packaging your application using Flatpak: http://flatpak.org/ so that you can package your application for both Fedora, and every other distribution out there that has Flatpak available to it.
That is no replacement for a native RPM package.
Kevin Kofler
You're right, it's better :)
----- Original Message -----
Bastien Nocera wrote:
I would advise you to look into packaging your application using Flatpak: http://flatpak.org/ so that you can package your application for both Fedora, and every other distribution out there that has Flatpak available to it.
That is no replacement for a native RPM package.
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, Dec 14, 2016 at 10:17 AM, Bastien Nocera bnocera@redhat.com wrote:
You're right, it's better :)
Not really. Flatpak is incredibly limited in its abilities. Applications that interface with hardware directly are out of the question, for example. That means lots of pro-AV applications simply won't work properly in that environment.
That is not 100% correct. You can make a non-sandboxed Flatpak and it would work just as well as an RPM in terms of hardware access. Enabling sandboxing however would need some thought and development for a lot of such applications, but we are slowly but surely working on it through things like the PulseAudio and Pinos work that Wim Taymans is doing, and through the work that Alex Larsson has been doing with OpenGL.
Christian
----- Original Message -----
From: "Neal Gompa" ngompa13@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Wednesday, December 14, 2016 10:21:32 AM Subject: Re: GSequencer upstream wants to package for fedora
On Wed, Dec 14, 2016 at 10:17 AM, Bastien Nocera bnocera@redhat.com wrote:
You're right, it's better :)
Not really. Flatpak is incredibly limited in its abilities. Applications that interface with hardware directly are out of the question, for example. That means lots of pro-AV applications simply won't work properly in that environment.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, Dec 14, 2016 at 10:27:36AM -0500, Christian Schaller wrote:
That is not 100% correct. You can make a non-sandboxed Flatpak and it would work just as well as an RPM in terms of hardware access. Enabling sandboxing however would need some thought and development for a lot of such applications, but we are slowly but surely working on it through things like the PulseAudio and Pinos work that Wim Taymans is doing, and through the work that Alex Larsson has been doing with OpenGL.
How far are we from "If it's an RPM in Fedora, we can automatically generate a Flatpak for you?"
On Wed, Dec 14, 2016 at 10:27 AM, Christian Schaller cschalle@redhat.com wrote:
That is not 100% correct. You can make a non-sandboxed Flatpak and it would work just as well as an RPM in terms of hardware access. Enabling sandboxing however would need some thought and development for a lot of such applications, but we are slowly but surely working on it through things like the PulseAudio and Pinos work that Wim Taymans is doing, and through the work that Alex Larsson has been doing with OpenGL.
There's also the fact that the runtimes provided also crash on most of my computers, but hey, that's just a small thing, right?
Speaking with my Fedora and Mageia hats, there's nothing that stops ANYONE from making portable RPMs (I've done it fairly easily myself). Flatpak, AppImage, Snappy, etc. do not provide any material advantages without some sandboxing. In fact, they just make applications more bloated for little to no benefit at that point.
IMO, the only reason that we're starting to see this is because we're increasingly giving up on Free Software (note capital letters). These systems primarily benefit nonfree/proprietary software developers.
Speaking with my Snappy hat on, the concept of making it possible for people to make applications that work everywhere and anywhere is a very nice dream. But it's important to realize that the integration work has to happen somewhere. Flatpak is moving too slowly in this regard, and while Snappy has this functionality in spades, it requires much deeper integration into the distribution than Flatpak does. The main things keeping snaps from being a first class citizen on Fedora are the inability to produce snaps based on a Fedora base and Fedora packages (that's being worked on) and the lack of SELinux integration (also being worked on).
I've personally been working on these things for the Snappy system, but the Flatpak guys seem to be doing *nothing* about it. I'm very disappointed in the progress of the Flatpak system.
To date, it is still not possible to install Flatpaks through Plasma Discover like it is through GNOME Software. It is not possible to build Flatpaks from RPMs in such a manner where Fedora-based runtimes could power software. (Hint: both GNOME and KDE app stores support Snappy!) There is no evangelism from the people working on Flatpak to demonstrate the technology and drive any useful interest. The sandboxing in Flatpak is so restrictive that it's not possible to use it for a very wide variety of common applications. Even applications like VLC are not properly functional in Flatpak, whereas they are as a Snap.
Speaking without any of my hats on, Flatpak and Snap both offer a different way to distribution various classes of applications. But we're still at the point where they are not overly useful. And I'm getting increasingly upset with the Fedora Workstation WG over their attitude of discouraging people from contributing software to Fedora as RPMs. The proposals I've seen from them about automatically removing RPMs in favor of Flatpaks or hiding them so that they are not obvious or easy to install are horrifyingly bad.
I'm increasingly worried that the Workstation WG has lost sight of our founding principles as a project, and are forgetting that our goal is to make the best Free system out there, to show that Free Software is the best model for producing a high-quality system.
What has happened to Fedora? What has happened to us?
That is a lot of different things mashed into one here, and while I can not even begin to understand how you can bash our commitment to Free Software and at the same time be an argent backer of Shuttleworths Snappy is beyond me, but I am sure is somehow makes sense to you.
Also I don't think it is true in any way or form that the Working Group is discouraging people from making RPMS, in fact I have personally talked to a lot of different companies and people over the last year encouraging to them to make RPMS. And Bastien Nocera who was the one on this thread encouraging making a Flatpak is not a Working Group member, in fact he is just a community member doing what he has every right to do, which is to advocate the solution he thinks is best for the problem at hand. And you of course have every right to advocate for a different approach, but I don't see why you think slagging the Workstation Working Group somehow is the correct response.
The proposals you misrepresent so wonderfully was a general issue of how do we deal with the same application being available in multiple formats, which is not even limited to RPM and Flatpak. Offering users 10 versions of the same application at the same version number with the only difference being the package technology used is confusing and stupid. And we need to have a policy for dealing with it and dealing with the fact that the recommended packaged version of an application might change their package format over time. This could go both ways, but of course since we have mostly RPMS these days the likelyhood is that at least in the beginning the most common case will mostly be away from RPMS. And to be clear the working group isn't spending time trying to figure out how we can offer the Gimp as a Flatpak for example, just because it is not a very interesting problem to solve, since we already have the Gimp as an RPM. Instead we are focusing on using Flatpaks as a method for bringing new applications to the Fedora ecosystem.
Christian
----- Original Message -----
From: "Neal Gompa" ngompa13@gmail.com To: "Development discussions related to Fedora" devel@lists.fedoraproject.org Sent: Wednesday, December 14, 2016 10:52:37 AM Subject: Re: GSequencer upstream wants to package for fedora
On Wed, Dec 14, 2016 at 10:27 AM, Christian Schaller cschalle@redhat.com wrote:
That is not 100% correct. You can make a non-sandboxed Flatpak and it would work just as well as an RPM in terms of hardware access. Enabling sandboxing however would need some thought and development for a lot of such applications, but we are slowly but surely working on it through things like the PulseAudio and Pinos work that Wim Taymans is doing, and through the work that Alex Larsson has been doing with OpenGL.
There's also the fact that the runtimes provided also crash on most of my computers, but hey, that's just a small thing, right?
Speaking with my Fedora and Mageia hats, there's nothing that stops ANYONE from making portable RPMs (I've done it fairly easily myself). Flatpak, AppImage, Snappy, etc. do not provide any material advantages without some sandboxing. In fact, they just make applications more bloated for little to no benefit at that point.
IMO, the only reason that we're starting to see this is because we're increasingly giving up on Free Software (note capital letters). These systems primarily benefit nonfree/proprietary software developers.
Speaking with my Snappy hat on, the concept of making it possible for people to make applications that work everywhere and anywhere is a very nice dream. But it's important to realize that the integration work has to happen somewhere. Flatpak is moving too slowly in this regard, and while Snappy has this functionality in spades, it requires much deeper integration into the distribution than Flatpak does. The main things keeping snaps from being a first class citizen on Fedora are the inability to produce snaps based on a Fedora base and Fedora packages (that's being worked on) and the lack of SELinux integration (also being worked on).
I've personally been working on these things for the Snappy system, but the Flatpak guys seem to be doing *nothing* about it. I'm very disappointed in the progress of the Flatpak system.
To date, it is still not possible to install Flatpaks through Plasma Discover like it is through GNOME Software. It is not possible to build Flatpaks from RPMs in such a manner where Fedora-based runtimes could power software. (Hint: both GNOME and KDE app stores support Snappy!) There is no evangelism from the people working on Flatpak to demonstrate the technology and drive any useful interest. The sandboxing in Flatpak is so restrictive that it's not possible to use it for a very wide variety of common applications. Even applications like VLC are not properly functional in Flatpak, whereas they are as a Snap.
Speaking without any of my hats on, Flatpak and Snap both offer a different way to distribution various classes of applications. But we're still at the point where they are not overly useful. And I'm getting increasingly upset with the Fedora Workstation WG over their attitude of discouraging people from contributing software to Fedora as RPMs. The proposals I've seen from them about automatically removing RPMs in favor of Flatpaks or hiding them so that they are not obvious or easy to install are horrifyingly bad.
I'm increasingly worried that the Workstation WG has lost sight of our founding principles as a project, and are forgetting that our goal is to make the best Free system out there, to show that Free Software is the best model for producing a high-quality system.
What has happened to Fedora? What has happened to us?
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Wed, Dec 14, 2016 at 10:52 AM, Neal Gompa ngompa13@gmail.com wrote:
On Wed, Dec 14, 2016 at 10:27 AM, Christian Schaller cschalle@redhat.com wrote:
That is not 100% correct. You can make a non-sandboxed Flatpak and it would work just as well as an RPM in terms of hardware access. Enabling sandboxing however would need some thought and development for a lot of such applications, but we are slowly but surely working on it through things like the PulseAudio and Pinos work that Wim Taymans is doing, and through the work that Alex Larsson has been doing with OpenGL.
There's also the fact that the runtimes provided also crash on most of my computers, but hey, that's just a small thing, right?
Speaking with my Fedora and Mageia hats, there's nothing that stops ANYONE from making portable RPMs (I've done it fairly easily myself). Flatpak, AppImage, Snappy, etc. do not provide any material advantages without some sandboxing. In fact, they just make applications more bloated for little to no benefit at that point.
IMO, the only reason that we're starting to see this is because we're increasingly giving up on Free Software (note capital letters). These systems primarily benefit nonfree/proprietary software developers.
I disagree with this assertion. Flatpak, snappy, docker containers, etc are not an indication people are giving up on Free Software. They are a mechanism the focuses on easing a developer's ability to distribute their software without worrying about learning arcane knowledge of each distro's packaging system. That non-free software possibly benefits from this as well is true, but irrelevant to the goals of these projects.
Ascribing that intention on such technologies is trolling and spreading FUD. Please do not do that.
josh
On 12/14/2016 05:55 PM, Josh Boyer wrote:
I disagree with this assertion. Flatpak, snappy, docker containers, etc are not an indication people are giving up on Free Software. They are a mechanism the focuses on easing a developer's ability to distribute their software without worrying about learning arcane knowledge of each distro's packaging system.
But these packaging systems produce source and binary packages at the same time. In contrast, I have yet to encounter a container build service which does that. This has the side effect that GPL compliance and general availability of matching source code is rather poor. As the result, free software loses.
Thanks, Florian
On Wed, Dec 14, 2016 at 12:09 PM, Florian Weimer fweimer@redhat.com wrote:
On 12/14/2016 05:55 PM, Josh Boyer wrote:
I disagree with this assertion. Flatpak, snappy, docker containers, etc are not an indication people are giving up on Free Software. They are a mechanism the focuses on easing a developer's ability to distribute their software without worrying about learning arcane knowledge of each distro's packaging system.
But these packaging systems produce source and binary packages at the same time. In contrast, I have yet to encounter a container build service which does that. This has the side effect that GPL compliance and general availability of matching source code is rather poor. As the result, free software loses.
That doesn't mean the technologies inherently exist to promote non-free software. It means 1) there are bugs that need to be fixed to solve the source issue, and 2) people are lazy and are not providing a clear mapping back to source with today's implementation. That same issue will continue even after the tools grow source distribution capabilities, because developers focus on their applications, not on compliance or writing documentation, etc.
josh
Florian Weimer wrote:
But these packaging systems produce source and binary packages at the same time. In contrast, I have yet to encounter a container build service which does that. This has the side effect that GPL compliance and general availability of matching source code is rather poor. As the result, free software loses.
Indeed, almost all the containers, app bundles etc. out there are outright illegal, because they just repackage a random distro's packages without including the corresponding SRPMs or equivalent. The full corresponding sources would usually be many times larger than the container, because a lot of libraries from different source packages are bundled.
And then there are cases like Electron where the official Electron "source" distribution defaults to using a libchromiumclient blob without the corresponding source code required by the LGPL license of large parts of Chromium, and applications then repackage a prebuilt Electron blob containing the libchromiumclient blob for an extra layer of intransparent blob bundling. Essentially all the Electron applications out there are distributed in violation of the LGPL.
Kevin Kofler
On Wed, Dec 14, 2016 at 11:17:01PM +0100, Kevin Kofler wrote:
Indeed, almost all the containers, app bundles etc. out there are outright illegal, because they just repackage a random distro's packages without including the corresponding SRPMs or equivalent. The full corresponding sources would usually be many times larger than the container, because a lot of libraries from different source packages are bundled.
Note that a significant feature of the Layered Image Build Service we just deployed in Fedora (which creates Docker-style OCI bundles) is the ability to trace back from binary to source we provide.
We'll do something similar when building Flatpaks.
Bastien Nocera wrote:
You're right, it's better :)
If you define "better" as larger download, higher use of RAM and disk space, less system integration, fewer and less timely security fixes and other bugfixes, etc., then yes, Flatpak is "better". ^^
See also https://fedoraproject.org/wiki/Bundled_Libraries – Flatpak requires you to bundle ALL libraries that are not part of the "runtime" bundle. Other similar systems even require you to really bundle ALL libraries without exception. But even Flatpak's split is nowhere near flexible enough.
Kevin Kofler
On 12/14/2016 11:17 AM, Bastien Nocera wrote:
You're right, it's better :)
By technology involved, true. But until there is a Fedora (or another distribution) flatpack build service, there is no replacement for a Fedora built RPM package. It doesn't matter you trust the developer, you must if you trust the source code, the problem is trusting random build machines that probably are personal desktop/laptops used for browsing or other things a build machine should not be doing
----- Original Message -----
Bastien Nocera wrote:
I would advise you to look into packaging your application using Flatpak: http://flatpak.org/ so that you can package your application for both Fedora, and every other distribution out there that has Flatpak available to it.
That is no replacement for a native RPM package.
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org