Packaging of flutter based software

Dear all, First of all, I may apologize for the question, which has maybe been asked already on this list. Still, a brief search did not yield substantial results, on how to deal with my topic of interest. I'm currently trying to package the yubioath-flutter (https://github.com/Yubico/yubioath-flutter) project for OpenSUSE. The old package for the same purpose, which was part of the OSS and the security repository is abandoned and the upstream project has been transferred to yubioath-flutter. Now comes my question: I had a look at the page for packaging guidelines, which states in one of the first paragraphs, that packaging shall be based on source code and not on binary packages (https://en.opensuse.org/openSUSE:Packaging_guidelines#No_inclusion_of_pre-bu...). Yet, when dealing with flutter based software, this meets a couple of issues, such as that flutter has not been officially packaged for OpenSUSE. Furthermore, the results obtained by running flutter on the repository is itself a statically linked binary again. Thus, I may ask for your advice on how to proceed in such a case? Is it necessary to package flutter for OSS in order to include it in the buildroot required for building or can proven and verified binaries be used? I appreciate your feedback Kind regards Thomas Rahimi

On Sun Dec 22, 2024 at 8:45 PM CET, Thomas Rahimi wrote:
Is it necessary to package flutter for OSS in order to include it in the buildroot required for building or can proven and verified binaries be used?
I am afraid that the answer is yes, which is the reason why nobody tried it. I mean, really the hard-no-negotiation-possible rule is that whole tool stack from the operating system all the way to the end-user application must be open source, the source must be distributable, and all binaries are built from such source code only. When Sun Microsystems released Java, there were some binary packages as part of the tarball, because there were parts of the code where even Sun itself didn’t have source code for it (a situation which happens surprisingly often in the proprietary universe; Microsoft doesn’t have complete source code for Windows, AFAIK). It took another almost a year, before these parts were reprogrammed from other Java-related projects [1], and before OpenJDK became part of the Linux distributions. Having said that, do you really have to maintain it as a part of openSUSE? Couldn’t you for example distribute and maintain this application as Flatpak? Flatpak community is much more relaxed about openness of their source, and they allow to distribute 100% proprietary code [2]. Happy Hacking! Matěj [1] https://en.wikipedia.org/wiki/GNU_Classpath, and https://en.wikipedia.org/wiki/GNU_Compiler_for_Java, and others [2] https://flathub.org/apps/us.zoom.Zoom and https://flathub.org/apps/com.skype.Client, to mention just two most glaring examples -- http://matej.ceplovi.cz/blog/, @mcepl@en.osm.town GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 It is a rare mind indeed that can render the hitherto non-existent blindingly obvious. The cry “I could have thought of that” is a very popular and misleading one, for the fact is that they didn’t, and a very significant and revealing fact it is too. -- Douglas Adams, Dirk Gently’s Holistic Detective Agency

Hello, thanks for the swift reply. I'm aware of the pitfalls, binary software brings along in systems, so I totally understand the answer and the intention included in it. There are already appimages or flatpaks available for the relevant software. Still, since there are dependencies, which are closer to the system, such as pcscd, I'd prefer to see yubioath being packaged as an RPM package. So I'll try to figure out during the holidays, how to package the overall chain of required packages. Once I got them up and running, my question would be, how can I submit them to be part of a central repository? Do I need to write tests for staging when submitting packages to OpenSUSE? Thanks a lot in advance Kind regards Thomas Am 22.12.24 um 22:31 schrieb Matěj Cepl:
On Sun Dec 22, 2024 at 8:45 PM CET, Thomas Rahimi wrote:
Is it necessary to package flutter for OSS in order to include it in the buildroot required for building or can proven and verified binaries be used?
I am afraid that the answer is yes, which is the reason why nobody tried it. I mean, really the hard-no-negotiation-possible rule is that whole tool stack from the operating system all the way to the end-user application must be open source, the source must be distributable, and all binaries are built from such source code only. When Sun Microsystems released Java, there were some binary packages as part of the tarball, because there were parts of the code where even Sun itself didn’t have source code for it (a situation which happens surprisingly often in the proprietary universe; Microsoft doesn’t have complete source code for Windows, AFAIK). It took another almost a year, before these parts were reprogrammed from other Java-related projects [1], and before OpenJDK became part of the Linux distributions.
Having said that, do you really have to maintain it as a part of openSUSE? Couldn’t you for example distribute and maintain this application as Flatpak? Flatpak community is much more relaxed about openness of their source, and they allow to distribute 100% proprietary code [2].
Happy Hacking!
Matěj
[1] https://en.wikipedia.org/wiki/GNU_Classpath, and https://en.wikipedia.org/wiki/GNU_Compiler_for_Java, and others [2] https://flathub.org/apps/us.zoom.Zoom and https://flathub.org/apps/com.skype.Client, to mention just two most glaring examples
-- Der Inhalt dieser Nachricht ist vertraulich und ausschließlich für die oben aufgeführten Empfänger bestimmt. Sollten Sie diese Nachricht irrtümlich erhalten haben, löschen Sie diese bitte. Für zukünftige Mailwechsel wäre eine Verschlüsselung der Mails sinnvoll, dafür befindet sich im Anhang der Mail mein öffentlicher Schlüssel. Sollten Sie Fragen haben, können Sie sich an mich wenden. Mit freundlichen Grüßen Thomas Rahimi thomas.rahimi@mailbox.org

On Mon Dec 23, 2024 at 7:51 AM CET, Thomas Rahimi wrote:
thanks for the swift reply. I'm aware of the pitfalls, binary software brings along in systems, so I totally understand the answer and the intention included in it. There are already appimages or flatpaks available for the relevant software. Still, since there are dependencies, which are closer to the system, such as pcscd, I'd prefer to see yubioath being packaged as an RPM package.
Do you have to have the package in Factory? Couldn’t you just keep it in your personal project?
So I'll try to figure out during the holidays, how to package the overall chain of required packages. Once I got them up and running, my question would be, how can I submit them to be part of a central repository? Do I need to write tests for staging when submitting packages to OpenSUSE?
I don’t think it is possible to package whole Flutter, it is almost impossible to even installed the thing. And you don’t need to make your own tests. Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@en.osm.town GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry

"Thomas Rahimi" <thomas.rahimi@mailbox.org> writes:
Furthermore, the results obtained by running flutter on the repository is itself a statically linked binary again. Thus, I may ask for your advice on how to proceed in such a case? Is it necessary to package flutter for OSS in order to include it in the buildroot required for building or can proven and verified binaries be used?
This is all true. The situation is kinda similar to Go I think. But first of all I think for testing purposes it should be enough to have all the tools in a test project to see how far you can get. For other languages such as JavaScript packaging applications has been extremely difficult even when they are fully oss.

On Tue Dec 24, 2024 at 10:22 PM CET, Björn Bidar wrote:
This is all true. The situation is kinda similar to Go I think. But first of all I think for testing purposes it should be enough to have all the tools in a test project to see how far you can get. For other languages such as JavaScript packaging applications has been extremely difficult even when they are fully oss.
The significant difference is that Go toolchain (compiler, cargo, etc.) is perfectly packaged in the normal manner and all vendored modules are only sources, which are compiled. Flutter seems to me (I have minimal experience with it) able to include various binaries both in the toolchain and in the vendored modules. Merry Christmas! Matěj -- http://matej.ceplovi.cz/blog/, @mcepl@en.osm.town GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare

Matěj Cepl <mcepl@cepl.eu> writes:
On Tue Dec 24, 2024 at 10:22 PM CET, Björn Bidar wrote:
This is all true. The situation is kinda similar to Go I think. But first of all I think for testing purposes it should be enough to have all the tools in a test project to see how far you can get. For other languages such as JavaScript packaging applications has been extremely difficult even when they are fully oss.
The significant difference is that Go toolchain (compiler, cargo, etc.) is perfectly packaged in the normal manner and all vendored modules are only sources, which are compiled. Flutter seems to me (I have minimal experience with it) able to include various binaries both in the toolchain and in the vendored modules.
Oh that sounds kinda unprofessional. However now when I think of my experience with Android Porting the git repositories for the prebuilds where separated from the source repositories. It would be worth to check out how these are structurized for Flutter.
Merry Christmas!
Thanks, to you to Björn

Hello everyone, thanks for all the feedback. I successfully figured out a plan, which involves building and packaging dart-sdk from source and in the next packaging flutter. Since dart-sdk is the only binary package in this regard, I assume this approach to be in line with the principles provided by the OpenSUSE project. I verified, up till this point, that any dependencies included during the building process for dart-sdk is provided as source code and thus the binaries provided in the package are created during the build process. The resulting packages will be: dart-lang-sdk and flutter-sdk Hope this serves your intention and brings some benefit for whoever wants to use these packages in the future. I expect my work to be completed with the beginning of January, which is next week. Kind regards Thomas Rahimi Am 25.12.24 um 17:56 schrieb Björn Bidar:
Matěj Cepl <mcepl@cepl.eu> writes:
On Tue Dec 24, 2024 at 10:22 PM CET, Björn Bidar wrote:
This is all true. The situation is kinda similar to Go I think. But first of all I think for testing purposes it should be enough to have all the tools in a test project to see how far you can get. For other languages such as JavaScript packaging applications has been extremely difficult even when they are fully oss.
The significant difference is that Go toolchain (compiler, cargo, etc.) is perfectly packaged in the normal manner and all vendored modules are only sources, which are compiled. Flutter seems to me (I have minimal experience with it) able to include various binaries both in the toolchain and in the vendored modules.
Oh that sounds kinda unprofessional. However now when I think of my experience with Android Porting the git repositories for the prebuilds where separated from the source repositories. It would be worth to check out how these are structurized for Flutter.
Merry Christmas!
Thanks, to you to
Björn
-- Der Inhalt dieser Nachricht ist vertraulich und ausschließlich für die oben aufgeführten Empfänger bestimmt. Sollten Sie diese Nachricht irrtümlich erhalten haben, löschen Sie diese bitte. Für zukünftige Mailwechsel wäre eine Verschlüsselung der Mails sinnvoll, dafür befindet sich im Anhang der Mail mein öffentlicher Schlüssel. Sollten Sie Fragen haben, können Sie sich an mich wenden. Mit freundlichen Grüßen Thomas Rahimi thomas.rahimi@mailbox.org
participants (3)
-
Björn Bidar
-
Matěj Cepl
-
Thomas Rahimi