On 2/23/21 11:46 AM, Zac Medico wrote: > On 2/20/21 8:17 PM, Zac Medico wrote: >> On 2/13/21 4:53 PM, Zac Medico wrote: >>> On 2/13/21 4:37 PM, Zac Medico wrote: >>>> On 2/11/21 1:17 AM, Michał Górny wrote: >>>>> On Wed, 2021-02-10 at 19:51 +0100, Lars Wendler wrote: >>>>>> On Wed, 10 Feb 2021 19:57:48 +0200 Andreas K. Hüttel wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I'm announcing a new project here - "binhost" >>>>>>> >>>>>>> "The Gentoo Binhost project aims to provide readily installable, >>>>>>> precompiled packages for a subset of configurations, via central >>>>>>> binary package hosting. Currently we are still in the conceptual >>>>>>> planning stage. " >>>>>>> >>>>>>> https://wiki.gentoo.org/wiki/Project:Binhost >>>>>>> >>>>>>> If you're interested in helping out, feel free to add yourself on the >>>>>>> wiki page. >>>>>>> >>>>>>> Note that I see actually *building* the packages not as the central >>>>>>> point of the project (that could be e.g. a side effect of a >>>>>>> tinderbox). I'm more concerned about >>>>>>> * what configurations should we use >>>>>>> * what portage features are still needed or need improvements (e.g. >>>>>>> binpkg signing and verification) >>>>>>> * how should hosting look like >>>>>>> * and how we can test this on a limited scale before it goes "into >>>>>>> production" >>>>>>> * ... >>>>>>> >>>>>>> Comments, ideas, flamebaits? :D >>>>>>> >>>>>>> Cheers, >>>>>>> Andreas >>>>>>> >>>>>> >>>>>> It would be great to improve portage speed with handling binpkgs. I >>>>>> already have my own binhost for a couple of Gentoo systems and even >>>>>> though these systems don't have to compile anything themselves, >>>>>> installing ~100 to ~200 binpkgs takes way more than an hour of >>>>>> installation time. Arch Linux' pacman only takes a fraction of this >>>>>> time for the very same task. >>>>>> I know that I compare apples with pears here but even reducing the >>>>>> current portage time by 50% would be a huge improvement. >>>>> >>>>> Is that really a problem? For me, Portage takes about an hour just to >>>>> do the dependency processing these days. In fact, building from sources >>>>> is now faster than dependency calculations. >>>> >>>> The ratio of these times is dependent on the complexity of the >>>> dependencies involved, and so is the answer to your question. >>> >>> Also, in the context of binary packages, dependencies calculations are >>> generally simpler for binary packages because their USE conditionals and >>> slot-operator := dependencies are frozen in a particular state. This >>> dramatically reduces the search space involved in dependency calculation. >> >> IUSE_RUNTIME will obviously introduce conditionals in binary package >> dependencies, but we should welcome these conditionals because they will >> provide useful flexibility. >> >> I think IUSE_RUNTIME will be a very nice feature to have for project >> binhost, since it will allow binary package dependencies to behave with >> flexibility that more closely resembles the flexibility of ebuild >> dependencies. > > We can borrow paludis's notion of pbins [1] to generate ebuilds which > install pre-built content, and the generated ebuilds could have USE > flags that behave similarly to IUSE_RUNTIME in the sense that changes to > USE flags will result in different builds of pre-built content being > installed. A content-hash distfiles layout [2] could serve as a > convenient way to store separate builds of pre-built content for > multiple combinations of USE flags, and a generated ebuild would index > the build by USE flag combination. > > Also, for the generated ebuilds, we can generate USE flags to include > separate SRC_URI downloads for pre-built content to support things like > FEATURES=split-debug and FEATURES=install-sources.
Note that all of this can existing EAPI features, since everything new would be implemented in an ebuild generator that generates a single ebuild to index pre-built content from multiple binary package builds. > [1] https://paludis.exherbo.org/overview/pbins.html > [2] https://bugs.gentoo.org/756778 -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature
