-
Notifications
You must be signed in to change notification settings - Fork 164
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
Make bulk/testport -b URL not only support official repositories, but any repository #1025
Comments
@bdrewery As promised, here is the issue to improve |
@bdrewery gave it some thoughts today since I don't want to live with a patch forever. Here is my idea how we could move this forward: As far as I understand only a single repo is supported since WDYT? I'd be willing to work on a PR if this is acceptable for you... Lengthly edit: I wanted to figure out whether poudriere would support a multi-repo setup. Here is what it looks like now and what I would like to have ideally in the future: graph
subgraph Wish
direction BT
FreeBSD_w[FreeBSD] --> ldadw-base_w[ldadw-base] & ldadocgen_w[ldadocgen] & general_w[general]
ldadw-base_w --> ldadocgen_w & general_w
end
subgraph Possible
direction BT
subgraph Currently Used
direction BT
FreeBSD_cu[FreeBSD] --> ldadw-base_cu[ldadw-base]
ldadw-base_cu[ldadw-base] --> ldadocgen_cu[ldadocgen]
end
subgraph ldadw-base
direction BT
FreeBSD_p_lb[FreeBSD] --> ldadw-base_p_lb[ldadw-base]
end
subgraph ldadocgen
direction BT
FreeBSD_p_ldg[FreeBSD] --> ldadocgen_p_ldg[ldadocgen]
end
subgraph general
direction BT
FreeBSD_p_g[FreeBSD] --> general_p_g[general]
end
end
I hacked poudriere/src/share/poudriere/common.sh Line 3831 in abc58e8
My "Wish" is not possible at all without making poudriere supporting such a multi-repo/multi-inheritance setup. My current setup is flawed as well because is is very limited. As far as I can see, I can only go with the middle setup for now, wasting cycles by rebuilding packages with custom options :-( I think that issue could be closed, but I would like to keep it open for reference for others at least until #798 has been merged and tested by people. |
I found this issue on my way to open my own. I came up with the same type of fix:
I use Seems like an easy fix would be to detect that |
That was my observation as well, but does not solve my wish situation where still only one repo is supported. |
Prerequisites
What is your proposal?
Remove the terms "official only" from this option and if any of the symbolic names,
latest
,quarterly
,release_X
keep repo nameFreeBSD
and enforce SRV RR, signatures, but when a custom URL is provided, setFreeBSD
tono
, add a new repo, e.g.,custom
where priority is higher (10?) and hardcodemirror_type
,pubkey
,signature_type
toNONE
. A more sophisticated way is to accept a file path where the admin can supply custom.conf
which contains arbitrary repos copied toLOCALBASE
into the jail. In this case it needs to be clarified how to provide public keys, if required. (This will provide nice layering of repos)What is the existing behavior, if any?
When providing the custom, selfhosted repo with
-b <URL>
the fetch fails because my packages aren't signed which I don't need nor is this an official repo.What is the motivation / use case for the change?
I build a base set of ports with custom options because the default ones do not work for our environment. Those options aren't only for direct, but also for automatic ones. On top there are several other use cases (sets) which use those base ports partially as dependency which I don't want to build over and over again. The option for
bulk
/testport
-b <URL>
expects only official repos which quite limits this nice feature. I want to use it with any selfhosted repo which will satisfy the fetch requirements.Did you consider any alternatives?
Yes, patching
common.sh
, but this is an ugly hack. More specificly, inpoudriere/src/share/poudriere/common.sh
Lines 3805 to 3809 in 5f69efb
Hack:
Is this really a ports feature request?
Yes, it is a poudriere issue.
Additional context
This was found in #883.
Real world example
port set
ldadw_base
:with the following in
/usr/local/etc/poudriere.d/
:123-release-amd64-default-ldadw_base-ports
:Available internally at
https://deblndw011x.ad001.siemens.net/FreeBSD/packages/${ABI}/ldadw-base
Now for a specific purpose bastille jail I have the following:
with the following in
/usr/local/etc/poudriere.d/
:123-release-amd64-default-ldadocgen-ports
:123-release-amd64-default-ldadocgen-options/
contains merged options fromldadw_base
andldadocgen
to satisfy-b
's requirements. Many of the ports inldadocgen
will use a lot fromldadw_base
, e.g., apache24, tomcat85, tomcat-native will use apr which inbase
has been pulled bysubversion
already along with many other build dependencies , e.g., ninja, cmake, GNU autotools, etc.The text was updated successfully, but these errors were encountered: