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
Enable libexec artifacts #408
Enable libexec artifacts #408
Changes from 5 commits
f930ca4
049dd28
b334181
d832058
4ac9745
dcbeca1
0d4ecc2
0d1a89e
fa22e90
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.
This doesn't look right.
The way we handle this for the other types (like libs) is always
<base>/<spec name>/<subpath>/<artifact name>
As an example, see how
Libs
are handled.Also at this time I'd like to avoid abstracting the behavior 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.
Let me double check a real system for common libexec usage, though.
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.
Yeah, I think that's the way to go, and if someone needs something directly in
/usr/libexec
or somewhere else they can use a symlink.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.
What about when packages are renamed from upstream? For example, if we have the moby-buildx package, we want the
docker-buildx
binary to go into/usr/libexec/docker/cli-plugins/docker-buildx
rather than/usr/libexec/moby-buildx/cli-plugins/docker-buildx
. IMO we should let the user do the right thing without adding extra steps.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.
That seems pretty non-standard. Pretty much everything in my
/usr/libexec
directory is either in/usr/libexec
directly, or nested under a single subdirectory bearing the main application's name. There's only a few files nested deeper than the application's name.That would violate the standard referenced in the PR description: "Applications may use a single subdirectory under /usr/libexec". If we create a symlink, we have one application (docker) with two subdirectories under
/usr/libexec
(/usr/libexec/docker
and/usr/libexec/moby-buildx
).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.
Maybe a separate field to overwrite the package name is worthwhile in this case.
Or just a bool like
OmitAutoPackageName
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.
done