GSequencer upstream wants to package for fedora

[Joël Krähemann]

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.

http://nongnu.org/gsequencer

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

[Michael Schwendt]

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

[Zbigniew Jędrzejewski-Szmek]

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:
>  
>  * 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 
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

[Joël Krähemann]

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(a)in.waw.pl&gt; 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:
>>
>> * 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
>
> 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

[Michael Schwendt]

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.

[Joël Krähemann]

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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Joël Krähemann]

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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

[Zbigniew Jędrzejewski-Szmek]

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:
>  >>
>  >> * 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
>  >
>  > 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

[Michael Schwendt]

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:
>  > >>
>  > >> * 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  
>  > >
>  > > 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.

[Zbigniew Jędrzejewski-Szmek]

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:
>  > > >>
>  > > >> *
> 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  
>  > > >
>  > > > 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

[Bastien Nocera]

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.
>  
>  http://nongnu.org/gsequencer
>  
>  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

[Kevin Kofler]

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

[Bastien Nocera]

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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[Neal Gompa]

On Wed, Dec 14, 2016 at 10:17 AM, Bastien Nocera <bnocera(a)redhat.com&gt; 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!

[Christian Schaller]

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(a)gmail.com&gt;
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org&gt;
> 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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[Matthew Miller]

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?"


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Neal Gompa]

On Wed, Dec 14, 2016 at 10:27 AM, Christian Schaller
<cschalle(a)redhat.com&gt; 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!

[Christian Schaller]

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(a)gmail.com&gt;
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org&gt;
> 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(a)redhat.com&gt; 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>

[Josh Boyer]

On Wed, Dec 14, 2016 at 10:52 AM, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Wed, Dec 14, 2016 at 10:27 AM, Christian Schaller
>  <cschalle(a)redhat.com&gt; 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

[Florian Weimer]

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

[Josh Boyer]

On Wed, Dec 14, 2016 at 12:09 PM, Florian Weimer <fweimer(a)redhat.com&gt; 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

[Kevin Kofler]

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

[Matthew Miller]

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.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Kevin Kofler]

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

[Robert Marcano]

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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> >
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>