Summary: | feature request: @universe package set for binhost management | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Christopher Fore <csfore> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | enhancement | CC: | gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Christopher Fore
2023-10-18 02:52:29 UTC
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). |