Seeing how binhosts are becoming more common among Gentoo users, an @universe package set might come in handy for those binhosters that just wish to have every package pre-compiled for any use case. For dependency conflicts, perhaps emerging @universe will only create a binpkg and will never actually install the packages directly to the system, preventing i.e. glibc and musl being installed at the same time. Potential con: This has the potential to create more overhead for the Portage devs as then they will have to create a specific edge case for @universe.
A package set has to be composed of a package list. How do you intend to generate the list of packages? Do you propose that @universe be generated from the list of all packages available some binhosts? Do you want to use all binhosts in binrepos.conf, or how do you want to choose the binhosts? We've go some sets existing sets here that may be useful for comparison: https://gitweb.gentoo.org/proj/portage.git/tree/lib/portage/_sets
Sorry for the delayed response! Been busy with college and a troublesome PowerBook. I (with some help from Immolo) came up with these possible ways to go about it: Assumptions made: USE flags will not change and the user wants to binhost for a different architecture from the host architecture. 1. Every package with $ARCH 2. The package set the official binhost has for $ARCH 3. Every package found across every overlay on the host? 4. A mix of the options above Pros of 1: - One command to run `emerge @universe` - Very simple to setup a binhost Cons of 1: - Storage requirements for a binhost increase drastically - Time to compile every package is huge - Tons of wasted packages (does one really need every package available?) Pros of 2: - Guaranteed to match what's "supported" - Storage requirements much lower Cons of 2: - More interaction needed if someone wants package X not in the set - Some architectures just.. don't have a binhost (i.e. ppc) Pros of 3: - Best for reproducability if the user wants package Y in overlay X Cons of 3: - No official support if package Y from unofficial overlay X fails to compile - Even more storage required than option 1
(In reply to xarvatium from comment #2) > Pros of 1: > - One command to run `emerge @universe` > - Very simple to setup a binhost I'm trying to understand why someone would want to run this command. Is the idea that they want to install all packages available from the binhost? If so, then I'm not sure why they would want to do that. Maybe this overlaps with bug 470006?
We might be having a misunderstanding of each other, the main idea behind it is to help aid people create binpkgs for a binhost, so people won't need to wait for an unexpected emerge during an install so it's a smooth process (i.e. if a medium-big package is being pulled in on older hardware and you don't have that package installed so now you need to emerge it and wait before continuing).
