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) Package seeding #554

Closed
wants to merge 2 commits into from
Closed

(WIP) Package seeding #554

wants to merge 2 commits into from

Conversation

yunchih
Copy link

@yunchih yunchih commented Nov 25, 2017

Right after the first clean_build_queue call:

  1. For all packages in ${MASTERMNT}/.p/all_pkgs, if it's not marked "listed" or if it's not in
    ${PACKAGES}/All, try fetch its ${pkg}-${ver}.txz from pkg.freebsd.org.
    If it succeeds, place the .txz into ${PACKAGES}/All.
  2. Call clean_build_queue to remove fetched packages from build queue.

It is still not clear to me whether to place fetched packages in ${PACKAGES}/All or in ${MASTERMNT}/packages/All. It seems that because ${MASTERMNT}/packages/All is in jail, it is read-only, but that is where clean_build_queue checks. Need help on this part.

Note: the code is still WIP and not working properly ...
Fix #319

@moufjenkins
Copy link

Can one of the admins verify this patch?

@yunchih
Copy link
Author

yunchih commented Dec 2, 2017

Any update on this? Any hint appreciated.


# Set up URL prefix
jail_version=$(jget ${JAILNAME} version)
# $MARJOR_RELEASE-$SUBRELEASE.RELEASE-px --> $MARJOR_RELEASE
Copy link

Choose a reason for hiding this comment

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

typo? s/MARJOR/MAJOR/ ?

Copy link
Author

Choose a reason for hiding this comment

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

Updated ( ;

[ $# -ne 3 ] && eargs pkg_seeding_download destination url originspec

msg_debug "Fetching seed from: $1"
fetch -q -a -w 1 -m -o "$2" "$1" &> /dev/null || \
Copy link

Choose a reason for hiding this comment

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

this could do with a comment; what value does the 2nd retry with different parameters bring here? does it solve an actual problem, and in the event of a failure can we rely on the retrieved package being correct? Should we check anywhere for validity, whether by SHA* or other method?

Copy link
Author

Choose a reason for hiding this comment

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

This kind of fetch retry is actually an imitation of the fetch_file function defined in the same file. Its purpose is to recover from potential jitterish network that fails the first fetch. However, we cannot verify the validity of fetched package without checking its SHA against pkg.freebsd.org's digests.txz. As this will add quite a bit complexity, I will backlog it for now and finish the most basic functionality first. 😸

@dch
Copy link

dch commented Dec 2, 2017

super idea - this is likely to help a lot of people move to poudriere for general port building.

I have one general question, if I read the code right, there is no way to detect if make.conf or custom config options for a dependent package (e.g. requiring an alternate SSL, or no docs, or some general version flag like DEFAULT_VERSIONS+=pgsql=9.5 for example) would invalidate the requested package relying on seeded dependencies. You'd end up with a newer postgres (or perl or ruby ...) dependency being used to build against an older requested package.

Is there a mechanism elsewhere in poudriere (the code to detect changed ports/options) that can be borrowed to cater for this?

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
@bdrewery
Copy link
Member

bdrewery commented Feb 9, 2018

It's a good start. It really needs to handle options, arch, versions, rather than blindly fetching and then possibly just deleting everything it just fetched. I'll bring it in and add the extra logic to handle that.

@0mp
Copy link
Member

0mp commented Nov 12, 2020

This is probably going to be implemented differently. See #797.

@bdrewery
Copy link
Member

bdrewery commented May 6, 2021

Thank you for this. It's been superseded by #797 which uses pkg.

@bdrewery bdrewery closed this May 6, 2021
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

Successfully merging this pull request may close these issues.

Try to fetch dependencies instead of building them locally
5 participants