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

Custom PKGDEST set outside of chroot confuses ccm (#30 again?) #66

Closed
Taijian opened this issue May 25, 2020 · 5 comments
Closed

Custom PKGDEST set outside of chroot confuses ccm (#30 again?) #66

Taijian opened this issue May 25, 2020 · 5 comments

Comments

@Taijian
Copy link
Contributor

Taijian commented May 25, 2020

Hi!

I think I recently ran into issue #30 again, because I, too, have modified /etc/makepkg.conf to add build packages to a local repo. I saw that at the end of the discussion in #30, you added a note to the man page, warning that this would lead to problems that you consider to be out of scope.
Now, you later removed that warning again - which leads me to be confused as to what your intent here is:
a) Should ccm be able to work with a custom PKGDEST and I just misconfigured it?
b) Should it work, but is buggy?
c) Do you still consider such behaviour to be out of scope, but just accidentially removed the note about it?

Just trying to get this sorted, no pressure to implement something you consider not to be in scope!

@graysky2
Copy link
Owner

Not sure why I removed the language from the man page. I believe the there is still not an easy way to support PKGDEST outside of the chroot. My intent is "c" at the moment :)

@Taijian
Copy link
Contributor Author

Taijian commented May 25, 2020

Ah... a pity, but understandable!

@graysky2
Copy link
Owner

Open to thoughts regarding handling it.

@Taijian
Copy link
Contributor Author

Taijian commented May 25, 2020

Yeah, pouring over your script for about an hour and thinking about it some more, I guess you are unfortunately (and non-surprisingly) right in that there does not really seem to be an easy way to do this, not least because I don't see an easy way of parsing the name(s) of the packages actually created by any given PKGBUILD.

One way I could see doing this is to add a new config option to $SKEL, e.g. $CUSTOM_AUR_REPO. We could then do the following:

  1. Not error out at the end of build() if the newly built package cannot be found and $CUSTOM_AUR_REPO is not empty
  2. Modify addit() to handle this case by elif-installing (all) the packages from $CUSTOM_AUR_REPO instead of erroring out
  3. Similarly modify create() to add packages from $CUSTOM_AUR_REPO to the chroot at creation time?

This would allow people to use a custom PKGDEST at the cost of a possibly slightly bloated chroot repo but would not affect the workflow of anyone who does not want to make use of it.

Does this make any sense to you or is this only a good idea in my head?

@Taijian
Copy link
Contributor Author

Taijian commented May 27, 2020

OK, apart from my brain fart of confusing build() with indexit(), here's a patch I've been trying in my setup. Seems to work, so far.
Missing: One line added to ccm.conf defining CUSTOM_AUR_REPO

ccm.patch.txt

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

No branches or pull requests

2 participants