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