New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flatpak/AppImage/Snap distribution #259

Open
edgmnt opened this Issue Oct 10, 2016 · 9 comments

Comments

Projects
None yet
3 participants
@edgmnt

edgmnt commented Oct 10, 2016

Consider packaging Haskell Platform for Flatpak, AppImage or Snap as Linux distribution-agnostic variants. It may even serve as a reference platform or testbed, since it's a better-controlled environment.

@gbaz

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Nov 6, 2016

Contributor

On initial inspection, it's not clear to me if appimage is distribution agnostic. Because it doesn't bundle everything there's the possibility of version mismatches? Flatpak looks more possible. That said, do you have examples of other compilers packaged in such a way? Distributing compilers this way feels somewhat different than distributing end-user applications -- some examples of how people have done this for one of these systems would be nice, to take inspiration from.

Contributor

gbaz commented Nov 6, 2016

On initial inspection, it's not clear to me if appimage is distribution agnostic. Because it doesn't bundle everything there's the possibility of version mismatches? Flatpak looks more possible. That said, do you have examples of other compilers packaged in such a way? Distributing compilers this way feels somewhat different than distributing end-user applications -- some examples of how people have done this for one of these systems would be nice, to take inspiration from.

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Nov 6, 2016

On initial inspection, it's not clear to me if appimage is distribution agnostic. Because it doesn't bundle everything there's the possibility of version mismatches?

AppImage is basically just a self-mounting filesystem that contains what you put in there. So, if you put the generic binaries from https://www.haskell.org/platform/#linux-generic inside an AppImage, the result should be no more and no less distribution agnostic than the generic binaries you used.

probonopd commented Nov 6, 2016

On initial inspection, it's not clear to me if appimage is distribution agnostic. Because it doesn't bundle everything there's the possibility of version mismatches?

AppImage is basically just a self-mounting filesystem that contains what you put in there. So, if you put the generic binaries from https://www.haskell.org/platform/#linux-generic inside an AppImage, the result should be no more and no less distribution agnostic than the generic binaries you used.

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Nov 6, 2016

I have it working in principle, but I can't get Haskell Platform activated as non-root. Can someone help me here? This has nothing to do with AppImage specifically - imagine you extract the generic binaries from https://www.haskell.org/platform/#linux-generic at some random location in your $HOME and want to activate/use them on a per-user basis, without being root. What are you supposed to do?

In case you are curious, here is the .yml file that puts together the AppImage, and here is the file that runs it.

probonopd commented Nov 6, 2016

I have it working in principle, but I can't get Haskell Platform activated as non-root. Can someone help me here? This has nothing to do with AppImage specifically - imagine you extract the generic binaries from https://www.haskell.org/platform/#linux-generic at some random location in your $HOME and want to activate/use them on a per-user basis, without being root. What are you supposed to do?

In case you are curious, here is the .yml file that puts together the AppImage, and here is the file that runs it.

@gbaz

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Nov 6, 2016

Contributor

This ticket seems to be relevant: #234

Contributor

gbaz commented Nov 6, 2016

This ticket seems to be relevant: #234

@gbaz

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Nov 6, 2016

Contributor

(It would be great if en passant to appimages or the like we also solved that more general non-root/relocatable problem in general)

Contributor

gbaz commented Nov 6, 2016

(It would be great if en passant to appimages or the like we also solved that more general non-root/relocatable problem in general)

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Nov 6, 2016

I don't entirely understand the script in #234 (comment) - where does this need to go? Do I have to run any other activate script in addition to it?

probonopd commented Nov 6, 2016

I don't entirely understand the script in #234 (comment) - where does this need to go? Do I have to run any other activate script in addition to it?

@gbaz

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Nov 6, 2016

Contributor

Not sure which script you mean. There, the script that's run on installing the generic distro is https://github.com/haskell/haskell-platform/blob/master/hptool/os-extras/posix/installer/install-haskell-platform.sh.mu

The suggestion is to then do a global find and replace on the bin subdirectory to fix up the following snippet, which is not a script per se, but is the header of each executable (since each are wrapped by a script that sets up their environment, and that script is hardcoded to the install location).

Its a bit weird to explain, but it makes sense once you just poke at the product of a generic install :-)

Contributor

gbaz commented Nov 6, 2016

Not sure which script you mean. There, the script that's run on installing the generic distro is https://github.com/haskell/haskell-platform/blob/master/hptool/os-extras/posix/installer/install-haskell-platform.sh.mu

The suggestion is to then do a global find and replace on the bin subdirectory to fix up the following snippet, which is not a script per se, but is the header of each executable (since each are wrapped by a script that sets up their environment, and that script is hardcoded to the install location).

Its a bit weird to explain, but it makes sense once you just poke at the product of a generic install :-)

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Nov 6, 2016

Each executable is wrapped in a script? Why that? Couldn't something like patchelf be used instead to set the library search path to $ORIGIN/../lib or something along these lines?

probonopd commented Nov 6, 2016

Each executable is wrapped in a script? Why that? Couldn't something like patchelf be used instead to set the library search path to $ORIGIN/../lib or something along these lines?

@gbaz

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Nov 6, 2016

Contributor

This sets a variety of paths, not just library search paths. As to exactly why and how its done the way it is -- you'd have to ask the GHC team. To the best of my knowledge this is already the way ghc does things, and the platform just wraps it...

Contributor

gbaz commented Nov 6, 2016

This sets a variety of paths, not just library search paths. As to exactly why and how its done the way it is -- you'd have to ask the GHC team. To the best of my knowledge this is already the way ghc does things, and the platform just wraps it...

probonopd added a commit to AppImage/AppImages that referenced this issue Nov 6, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment