<div dir="ltr">All of these questions are related, so I'll just comment generally ...<div><br></div><div>There is a method of registering "plugins" to a flatpak app ( which I haven't used yet ), which in theory could add a Perl distribution and "base" libraries. But I don't think this would be practical unless you could make this Perl base plugin available at build time ... as additional Perl libraries will often require their own set of Perl dependencies.</div><div><br></div><div>When I started out building my app, I asked about adding Perl to the various flatpak runtimes, and there was some discussion, but it didn't go anywhere. From memory, there were concerns about adding to the size of the runtime. I guess this has to be considered against the relative number of Perl devs building flatpak apps - I assume there aren't very many of us ... and some users do like to scream about "bloat". Not having Perl in a runtime did slow me down quite a bit in the beginning ( actually it slowed me down by about a year ) - mainly due to issues I encountered building Perl in the container or whatever it is that forces a read-only filesystem on us. Once I was pointed at some existing flatpak-builder examples that had Perl, I was on my way and honestly I don't care too much now.</div><div><br></div><div>If there is sufficient interest in having Perl in a runtime, maybe the approach would be to fork one of the runtimes and add Perl + goodies to it. I'm not sure how much work would be involved in maintaining such a thing.</div><div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 1, 2018 at 3:55 AM Mildred Ki'Lya <<a href="mailto:mildred@mildred.fr">mildred@mildred.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I am trying to write flatpaks manifests for irssi (yesterday I was targetting weechat, but it seems irssi is best). Doing so, I have a few question (some I asked over at GitHub which is probably not the best place, probably). I have a more in deph question now, and I wanted advice in what's best and how Flatpak aims at providing a solution.<br>
<br>
Irssi is a chat client that allows scripting in perl. During build, perl appears to be on the Sdk so it does not seem that I need to add a perl installation. However when using `flatpak run` it's no longer using the Sdk but the platform runtime instead. So no perl at runtime and irssi can't start because .so object is not found. Simple solution is to install perl alongside irssi. Perl being a module nested within irssi so when irssi is built, it can refer to the existing perl installation, and not the SDK installation.<br>
<br>
Question 1: Shouldn't be Perl be an addon to the runtime? Such as the applications requiring Perl could share the same perl installation, avoiding duplicating perl in each application build ?<br>
<br>
Now, irssi starts nicely, but when I try to use irssi scripts, all the scripts are complaining about missing perl modules. I added a flatpak module for each perl module that I found required by scripts. Those are numerous, and I think that we could share writing the flatpak manifest for them. For example I see Hexchat has perl scripting too. Both applications could benefit from a common collection of Perl modules.<br>
<br>
Question 2: Shouldn't common perl modules like this be part of an addon too? Would that make sense? Where would be the home for such a project?<br>
<br>
Next, I have a question about how modules are built. In my flatpak manifest file, I have the following module hierarchy:<br>
<br>
- irssi<br>
- perl installation<br>
- libwww-perl<br>
- perl-HTTP-Message<br>
- perl-URI<br>
- ...<br>
<br>
It means that the perl modules are not built against the perl installation that will be executing in the flatpak, but they are all building using the perl installation bundled within the Sdk. it means that if the Sdk contains perl 5.20 and I'm installing perl 5.28, all the modules will be built and compiled against Perl 5.20 and executed against Perl 5.28. Not really nice and that can cause issues.<br>
<br>
Question 3: Can I specify that irssi and all the perl modules share a common module dependency: the perl installation? it seems not possible with the current manifest format. Would moving Perl as a runtime addon fix that issue and is that the recommended move?<br>
<br>
Now, last question,<br>
<br>
Question 4: This flatpak mnifest will contain a great many perl modules. Is there some quick way to make them available within the flatpak, such as reusing distribution packages? Or perhaps should the flatpak modules be made reusable? Are we not duplicating the linux distributions work, but with flatpak-builder intsead of deb or rpm? Perhaps we can work with distributions so we can share part of the work (legal licencing issues, updates, including security updates, ...).<br>
<br>
Thank you.<br>
_______________________________________________<br>
Flatpak mailing list<br>
<a href="mailto:Flatpak@lists.freedesktop.org" target="_blank">Flatpak@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/flatpak" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/flatpak</a><br>
</blockquote></div>