Hi Jean-Marc, Pavel, What I was thinking is a joint effort. If you do want to maintain snaps long-term (emphasis on if), then you would need to understand and master the process, which is why it is handy for you to get familiar with the tooling. That said, I can also help, prototype, test, provide pointers, even do joint sessions if you like.
Regarding LyX's environment, I'm aware that is quite complex. Back in the day, I used miktex in windows to get latex packages, and similarly, the Linux repos need to have all of the available libraries to allow the full functionality. But here's how I see it working, rough architecture: - Snaps are aligned to a specific base (which is aligned to one of the Ubuntu LTS). Let's say core20 base = Ubuntu 20.04. - This means that whatever's inside the snap acts as though it's running on top of Ubuntu 20.04 even though the actual host could be Ubuntu 18.04, Fedora 34, whatever. - This means that you could technically grab all of the libs available for Ubuntu (and/or compiled for Ubuntu) and bundle them into a LyX content snap. The content snap could include LyX fonts, latex math formulas, additional packages, etc. - Separately, build the actual LyX program as its own snap. It should also probably bundle gs, ps, texlive, and some other utilities. - When installed, the LyX snap connects to the LyX content snap, and users have access to the required libraries. The big advantage in terms of maintenance is that you then do not need to rebuild and recompile everything for every distro. Depending on how your work is structured, this could be a big timesaver. But then, you probably have optimized workloads to begin with, so this is a guess on my end. If this is too optimistic on my end, no worries! LyX is awesome as it is, and my thinking is only in getting it to be as easily accessible to Linux users as possible. I added a couple of links to some documentation below, which might give you an indication of how to get going. Similarly, I added a link to the LibreOffice yaml, so again you get an understanding of what the structure of the build "recipe" for an office/text suite is like. https://snapcraft.io/docs/base-snaps https://snapcraft.io/docs/content-interface https://snapcraft.io/blog/introduction-to-snapcraft https://github.com/ubuntu/libreoffice/blob/7.2/snapcraft.yaml Thanks, Igor On Tue, Mar 22, 2022 at 6:49 PM Pavel Sanda <sa...@lyx.org> wrote: > On Tue, Mar 22, 2022 at 11:45:14AM +0000, Igor Ljubuncic wrote: > > I wanted to ask you if you'd be interested in packaging LyX as a snap and > > publishing it in the Snap Store? > > We would be definitiely interested in having it. > > > I know this would be a significant effort, but we could help of course, > and > > also feature LyX once it's ready. Regardless, this would be an amazing > > thing. > > > > Let me know what you think. > > It is not clear to me what actually you offer. Do you propose that > a) we do the major effort while you give us helping hand > b) you do the major effort while we give you helping hand > > I tried to look on flatpack support some time ago and backed off. > The major problem is that LyX relies on lot of tools around in order > to work properly which either means lot of tools porting or sanboxing > issues of already ported ones. If you are flatpack expert then it's > doable but if you are LyX-er which should learn nitty gritty detail > for one-shot release of LyX it does not pay off. > > So back to your question if you propose a) I am sceptical we do have > anyone in the team with time to get into details of snap packaging > to do all the work. > > On the other hand if you offer b) then I am happy to help in the sense > of providing details of LyX rough corners we encounter for the snap, > commiting necessary changes into our codebase, and give it some testing > time on one ubuntu machine I have access to... > > Pavel >
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
