Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
AUR packaging #19837
AUR packaging #19837
Changes from 3 commits
2ad1942
d3e4bb9
3571c70
a0c0a15
8e4f936
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, this checks that
chpl
runs before it is installed, right? I think the problem we are seeing is that something about the install process is not working right, so that's why this can pass even though the package is not working. Is there a post-install check available in some way (maybe just for people editing the AUR package and not necessarily something that runs when somebody installs the AUR package)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's my understanding as well, and I think that could be the case.
It is possible for me to include a post install script, but I'm not sure how integrated it is in the build and install process, since the package will already be installed. The one example I have hear is people using this script to bring up end user license agreement and so on, but I'm sure we can get it do more. What exactly were you thinking would go in here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just thinking it would be nice to have some scripting so that the maintainer of the Chapel AUR package can easily check that the installation is working. I.e. it could just be a script that you know how to run after installing. If we have that, we can (eventually) get some nightly testing config to check it as well.
I don't know whether or not it would be reasonable to do this with an AUR post install script but I suspect you wouldn't want people just installing the package to always run it. (So then not a post-install).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree post-install is probably not the right tool here, but something like you describe would be nice.
I think the typical approach for AUR packages is to do verification with
make check
before install, but that didn't work for us. I'm sure there are issues with this approach, but the way I was going to verify that the installation is working is just by building and running it myself (then addressing user issues as they appear in comments on AUR). This is less of a problem forchapel
since it's frozen until the next release, but perhaps would be problematic forchapel-git
which changes (and possibly breaks) with every PR.