-
Notifications
You must be signed in to change notification settings - Fork 162
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
Try to fetch dependencies instead of building them locally #319
Comments
Yes this is a wanted feature. I've called it 'package seeding'. The pkg.freebsd.org build script actually does this itself so we can build on different systems between each build. It's been on the TODOLIST forever but not yet implemented in Poudriere. |
Also recently started to actively use poudriere to build packages for themselves and would like a similar function for the |
Is this already implemented in a branch, I'd like to help to test it. |
It's not yet implemented in Poudriere but I'm scheduled it for after the next release. |
Sometimes it is not necessary to build ports that has been built elsewhere with default options. Just pull them over and use them if they are just dependencies of the ports we really want to build ourselves. In particular, we can opportunistically pull binary packages from pkg.freebsd.org if they have the exact version we want. Fix freebsd#319
Sometimes it is not necessary to build ports that has been built elsewhere with default options. Just pull them over and use them if they are just dependencies of the ports we really want to build ourselves. In particular, we can opportunistically pull binary packages from pkg.freebsd.org if they have the exact version we want. Fix freebsd#319
Sometimes it is not necessary to build ports that has been built elsewhere with default options. Just pull them over and use them if they are just dependencies of the ports we really want to build ourselves. In particular, we can opportunistically pull binary packages from pkg.freebsd.org if they have the exact version we want. Fix freebsd#319
Sometimes it is not necessary to build ports that has been built elsewhere with default options. Just pull them over and use them if they are just dependencies of the ports we really want to build ourselves. In particular, we can opportunistically pull binary packages from pkg.freebsd.org if they have the exact version we want. Fix freebsd#319
Hi, @bdrewery any update on this patch? Really need your feedback on how I can refine this patch. Any hint appreciated. Thanks a lot. |
Sorry I'm been quite busy lately. I'll try to look in the next few weeks. |
any new info? thanks! |
This would be very nice feature to have. I just updated to 3.3.99.20190311, but didn't see an option for pkg seeding. Is there news on this feature? |
In the mean time, I am using some hackish way to do this: https://github.com/lwhsu/freebsd-ports-libreoffice/blob/master/porttest.sh |
Well, try to |
@bdrewery any hope to see this feature soon enough? |
Not likely as my focus is elsewhere, such as building less in incremental build and distributed support. |
Any update coming for this issue? Is there anything we can do to help? |
Sorry for another "me too". I do like to build some ports that I'm using, as I've selected special flags on them. Things like Mesa et al. need a specific LLVM version though, and, well, I really don't want or need to build that myself. So it would be great if I could tell poudriere for some select ports to never build them, but fetch them instead. Otherwise, my run ends up like so:
I'd like to avoid that pointless churn. Thanks! |
@uqs I hear you. I also think that there is another way to solve that particular problem, which is getting official packages built using the flags that you want. Could you share details on what flags you change? |
Another me too here. Namely, I need the dns/unbound port with python, but I don't need to have all underlying dependencies built. |
+1 |
1 similar comment
+1 |
Either this feature or some documentation on how to use hooks to to achieve the same would be great! |
#797 will cover this |
Testing ports before committing changes is expensive. So, is building overlay of a few ports with non-default options.
/head
is a fast moving target,ports -u
often renders many out-of-date4 * 2 = 8
platform combinationsNO_ARCH
,NO_OSREL
,NO_OPSYS
yetFortunately, pkg.freebsd.org already provides ready-to-use packages. Why not take advantage? Caveat: only useful when local ports tree and remote snapshot at the time don't diverge much.
The text was updated successfully, but these errors were encountered: