Skip to content

Adds KaOS support#5535

Closed
ShalokShalom wants to merge 3 commits into
commercialhaskell:masterfrom
ShalokShalom:patch-1
Closed

Adds KaOS support#5535
ShalokShalom wants to merge 3 commits into
commercialhaskell:masterfrom
ShalokShalom:patch-1

Conversation

@ShalokShalom
Copy link
Copy Markdown

See this: #5452

Is this something I am supposed to mention in the change.log?

Then I do it

Copy link
Copy Markdown
Author

@ShalokShalom ShalokShalom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a mistake and hardcoded that one, how can we detect the version of ghc-tinfo6 easily?

Comment thread etc/scripts/get-stack.sh Outdated
printf "To be detectable by IDEs and other applications is it recommended to symlink \e[34mGHC\e[0m to the PATH.\nDo you like to do that?"
read -p " y or n: " yn
case $yn in
[Yy]*) sudo ln -s /home/$USER/.stack/programs/x86_64-linux/ghc-tinfo6-8.8.4/bin/ghc /usr/bin; break;;
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line can only work when we soft code the version

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think install scripts should ever do this. /usr/bin is controlled by your distros package manager.

Also note that there is a sudocmd function:

sudocmd() {

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you suggest a different dir for the PATH?
And using sudocmd instead sudo?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My opinion is to not do anything here. Global GHC installations is probably not in the scope the install script. IDEs like HLS work with stack just fine without exposing a global GHC.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its exactly what this script does for Debian and Co, no?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And vscode does not

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its exactly what this script does for Debian and Co, no?

I don't think so.

@mpilgrem
Copy link
Copy Markdown
Member

I would like to resolve this pull request, one way or another. I am a Windows user, so forgive me if I take things step-by-step and ask questions that may seem obvious to a Linux user.

I understand that KaOS is a Linux distribution that is x86-64-specific, and kcp is a KaOS package manager. I also understand from the above that KaOS can use the generic Linux GHC binary, but needs kcp package libtinfo(https://kaos-community-packages.github.io/items/libtinfo.html) as a pre-requisite. Is that correct? Does KaOS not come with something that other Linux distributions provide as standard?

Other parts of the script (for other Linux distribtions) have things like this:

do_fedora_install() {
  install_dependencies() {
    dnf_install_pkgs perl make automake gcc gmp-devel libffi zlib-devel xz tar git gnupg
  }

  if is_x86_64 ; then
    install_dependencies "$1"
    print_bindist_notice
    install_x86_64_linux_binary
  else
    die "Sorry, currently only 64-bit (x86_64) Linux binary is available."
  fi
}

# Install packages using dnf
dnf_install_pkgs() {
  if ! sudocmd "install required system dependencies" dnf install -y ${QUIET:+-q} "$@"; then
    die "\nInstalling dnf packages failed.  Please run 'dnf check-update' and try again."
  fi
}

Should KaOS/kcp follow the same 'pattern' for its libtinfo need? What is it about libtinfo that a warning is required before it is installed?

Is libtinfo the only dependency that is required if the distribution is KaOS? Distributions such as Ubuntu and Fedora seem to have a list of things that are needed?

I wondered why KaOS is introduced via do_sloppy_install() and not as its own case "$DISTRO" in do_distro(), if it is now being catered for expressly?

The addition of a link in /usr/bin to a particular version of GHC in Stack's 'sandbox' looks wrong to me. If a KaOS user also wanted a specific version of GHC on the PATH (as well as the Stack-supplied ones), would they not just install it?

@ShalokShalom
Copy link
Copy Markdown
Author

Wonderful 😄

Yes, you are basically correct about everything - the only thing I like to mention, is that libtinfo is build by the community and kcp is also a package manager for the community repo.

I only asked, if said dependency is fine to be added, since some people are quite sensitive about that.

I personally think its perfectly fine. 👍🏼

I love to introduce KaOS on the same level and with the same syntax as other distros, I think I was just to shy and hesitant to actually change something of the existing code.

You are also right about hard coding a specific version.

The only thing that is important to me, is to have an option to let the user choose to automatically add the compiler to the PATH.

Preferably, by scanning the sub directories, or simply by choosing the most recent version.

This way, people can just start coding. 🥳

ShalokShalom and others added 3 commits August 16, 2022 19:05
This detects KaOS with lsb_release.

HINT: While working on this, I realized, that there is no entry for Arch, despite being implemented otherwise. 
Does it work even?

KaOS is the name that lsb_release gives me in the Konsole, I guess your Perl foo magic converts it in lowercase letters, like the other distro names?
@mpilgrem
Copy link
Copy Markdown
Member

@ShalokShalom, I rebased on the master branch.

Some of my comments above were not apt - I was mislead by the way that the GitHub UI presented the changes in the file. I now understand that lines 425-427 are not part of do_sloppy_install().

I have:

  • added a kcp_install_pkgs(). I could not find online any comprehensive documentation of the kcp command line interface. I hope I have understood how the command works. I got the impression that it can only install one package at a time.

  • followed the pattern of other functions in do_kaos_install().

I am not in a position to test what I have done. Does the revised script actually work?

@ShalokShalom
Copy link
Copy Markdown
Author

Sorry, I am not on KaOS anymore.

@mpilgrem
Copy link
Copy Markdown
Member

mpilgrem commented Sep 5, 2022

I asked for testers on the Haskell Community but had no response. I am going to close this pull request. It can be reopened if another KaOS user and Haskeller emerges.

@mpilgrem mpilgrem closed this Sep 5, 2022
@ShalokShalom
Copy link
Copy Markdown
Author

ShalokShalom commented Sep 6, 2022

I just have no time at the moment. I tried to install KaOS in Virtualbox, but failed.

Will try if I find the time

@ShalokShalom ShalokShalom deleted the patch-1 branch March 10, 2024 20:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants