-
Notifications
You must be signed in to change notification settings - Fork 19
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
Comments
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 :) |
Ah... a pity, but understandable! |
Open to thoughts regarding handling it. |
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
This would allow people to use a custom Does this make any sense to you or is this only a good idea in my head? |
OK, apart from my brain fart of confusing |
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!
The text was updated successfully, but these errors were encountered: