Skip to content
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

[WIP] Makefile: set CONTAINERSCONFDIR based on the OS #1507

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

lsm5
Copy link
Member

@lsm5 lsm5 commented Nov 16, 2021

This will put config dir under $PREFIX for FreeBSD.

Continuing PR#1298 by @mateuszkwiatkowski.

Fixes: #787

Signed-off-by: Lokesh Mandvekar lsm5@fedoraproject.org

@lsm5 lsm5 changed the title Makefile: set CONTAINERSCONFDIR based on the OS. [WIP] Makefile: set CONTAINERSCONFDIR based on the OS Nov 16, 2021
This will put config dir under $PREFIX for FreeBSD.

Continuing PR#1298 by @mateuszkwiatkowski.

Fixes: containers#787

Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
@lsm5
Copy link
Member Author

lsm5 commented Nov 16, 2021

@glensc @mateuszkwiatkowski would either of you have the time to give this a try please?

@glensc
Copy link
Contributor

glensc commented Nov 16, 2021

PR #1298 - i like links

@glensc
Copy link
Contributor

glensc commented Nov 16, 2021

Copy link
Contributor

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

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

This doesn’t seem to resolve the concerns in #1298 (comment) ; just silently switching a default on an upgrade, and having defaults different from Buildah/Podman (ideally from the c/image builtins), is not desirable.

Making that change exclusive to macOS and FreeBSD makes it less problematic for Linux, but still problematic for the two, I think.

-X github.com/containers/image/v5/docker.systemRegistriesDirPath=${REGISTRIESDDIR} \
-X github.com/containers/image/v5/signature.systemDefaultPolicyPath=${CONTAINERSCONFDIR}/policy.json \
-X github.com/containers/image/v5/pkg/sysregistriesv2.systemRegistriesConfPath=${CONTAINERSCONFDIR}/registries.conf \
-X github.com/containers/image/v5/internal/tmpdir.unixTempDirForBigFiles=/var/tmp \
Copy link
Contributor

Choose a reason for hiding this comment

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

This overrides the hard-coded path with the same hard-coded path, AFAICS; why?

Copy link
Contributor

Choose a reason for hiding this comment

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

probably to be explicit and indicate it's a path that can be configured. copy paste from brew recipe.

Copy link
Member Author

@lsm5 lsm5 Nov 17, 2021

Choose a reason for hiding this comment

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

This doesn’t seem to resolve the concerns in #1298 (comment) ; just silently switching a default on an upgrade, and having defaults different from Buildah/Podman (ideally from the c/image builtins), is not desirable.

Making that change exclusive to macOS and FreeBSD makes it less problematic for Linux, but still problematic for the two, I think.

@mtrmac so would you prefer the same change be done across the board? If macos and freebsd prefer it in /usr/local, then I imagine this change has to be done at some point, yes?

The extra ldflag lines were a copy-paste from the older PR. I could make those conditional for homebrew / FreeBSD if they prefer to have them. @glensc @mateuszkwiatkowski wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

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

If macos and freebsd prefer it in /usr/local, then I imagine this change has to be done at some point, yes?

No?

Users who use Brew or other build systems that already override the paths can continue to use those build systems. Users who use make install would be broken on upgrade if we just changed the default with no compatibility mechanism; so we shouldn’t just change the default.

My view of #1298 is that adding reliable variables (like CONTAINERSCONFDIR or whatever), which would help Brew reliably work, is obviously useful and desirable; changing what the variable point to, by default, is not.

Copy link
Contributor

Choose a reason for hiding this comment

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

Alternatively, we could work to actually provide a compatibility mechanism (i.e. support at least two paths in c/image, and configure them to… something in there and possibly here). I don’t see that that work and complexity helps any known existing user — though it would help users who cross-grade between packaging systems like Brew and manual make install.

@github-actions
Copy link

A friendly reminder that this PR had no activity for 30 days.

@glensc
Copy link
Contributor

glensc commented Jan 10, 2022

Can this be finished? so i don't have to bump brew PR to keep it active:

@rhatdan
Copy link
Member

rhatdan commented Jan 10, 2022

@glensc @lsm5 is on PTO until the end of the month, I believe. If you want this to move forward, I suggest you take it over and open a new PR, following @mtrmac recommendations.

@mtrmac
Copy link
Contributor

mtrmac commented May 10, 2022

Changes in the meantime: #1642 + containers/image#1544 will move the config files to /usr/local/etc on FreeBSD (but not macOS like this PR also does); the transition will be an incompatible break but at least it will (eventually) be consistent with other c/image users.

At least the other aspect of this PR, making the directory overrides turn into c/image built-in path overrides, is still valuable and desirable for #787 .

@github-actions github-actions bot removed the stale-pr label May 27, 2022
@github-actions
Copy link

A friendly reminder that this PR had no activity for 30 days.

@mtrmac mtrmac added the kind/bug A defect in an existing functionality (or a PR fixing it) label Dec 7, 2022
@github-actions github-actions bot removed the stale-pr label Dec 9, 2022
Copy link

A friendly reminder that this PR had no activity for 30 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A defect in an existing functionality (or a PR fixing it) stale-pr
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Help for overriding paths during build
4 participants