| Summary: | sys-apps/portage: support --binhost-profile to avoid superfluous syncing | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Jason A. Donenfeld <zx2c4> |
| Component: | Binary packages support | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | alexander |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=644990 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Jason A. Donenfeld
2013-05-15 21:23:12 UTC
There's really not a lot of useful profile information inside the binhost's Packages file, so I'm not sure if it's really worth it to automate pulling profile data from there. I'm thinking that you should just create an empty /etc/portage/make.profile directory, set your ARCH in /etc/portage/make.profile/make.defaults, and leave it at that. If make.defaults exists, then that's enough to satisfy portage, since this commit: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=18aa5cc076a5597ba7e256f316835606bb5b6df9 Missing pieces: * system set (comes from 'packages' files in the profile) * selected set (comes from /var/lib/portage/world on the binhost) * package.provided We have have the binhost export all of these through the Packages file. I'm concerned about package.provided though, because it implies that there exists some separate channel for syncing the "provided" packages. If such a separate channel exists, then why not also used it to sync things like $PORTDIR/profiles and /var/lib/portage/world from the binhost? > If such a separate channel exists, then why not also used it to sync things
For example, a kernel of a virtual machine.
For EAPI 5, we need to include the implicit IUSE. PMS refers to it as IUSE_EFFECTIVE, and portage writes /var/db/pkg/*/*/IUSE_EFFECTIVE entries for EAPI 5. So, let's add a IUSE_EFFECTIVE setting in the Packages header section, and all of the EAPI 5 binary packages can use that. Include implicit IUSE vars in binhost Packages: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=85f53097ed9fad43b713ac9c13f6beff43da760e !!! Section 'gentoo' in repos.conf refers to repository without repository name set in '/usr/portage/profiles/repo_name'
!!! main-repo not set in DEFAULT and PORTDIR is empty.
WARNING: One or more repositories have missing repo_name entries:
/usr/portage/profiles/repo_name
NOTE: Each repo_name entry should be a plain text file containing a
unique name for the repository on the first line.
====
If repos.conf does not exist, it should not be checked like what happens with the above error message. Binpkg-only hosts do not need a repo.
Disable the main-repo warning: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1a6374733c62b1d131a0f2c9da6190364df6e3df You're going to have to negate the config from /usr/share/portage/config/repos.conf somehow. Currently, one way you can do that is to export PORTAGE_REPOSITORIES="" in your environment. Another way would be to comment out the lines or completely remove /usr/share/portage/config/repos.conf. Wondering where we stand with this. Is a minimal make.profile still required, or can we get rid of this now? In order to get rid of make.profile, we first need to resolve bug 640318. I'm currently working on this, I have some work in progress available in these branches, with TODO notes in the commit messages to explain what's not finished yet: https://github.com/zmedico/portage/tree/bug_640318_binary_iuse_implicit https://github.com/zmedico/portage/tree/bug_640318_bindbapi_override_iuse_implicit_cnstr The last patch from bug 640318 is included in portage-2.3.31. With emerge --usepkgonly, make.profile can be a directory containing a single 'parent' file that contains /var/empty as the parent, and that's enough to emerge binary packages. When we add the --binhost-profile option, it can disable the make.profile assertions. |