| 1 |
On 2/23/21 12:05 PM, Zac Medico wrote: |
| 2 |
> On 2/23/21 11:46 AM, Zac Medico wrote: |
| 3 |
>> On 2/20/21 8:17 PM, Zac Medico wrote: |
| 4 |
>>> IUSE_RUNTIME will obviously introduce conditionals in binary package |
| 5 |
>>> dependencies, but we should welcome these conditionals because they will |
| 6 |
>>> provide useful flexibility. |
| 7 |
>>> |
| 8 |
>>> I think IUSE_RUNTIME will be a very nice feature to have for project |
| 9 |
>>> binhost, since it will allow binary package dependencies to behave with |
| 10 |
>>> flexibility that more closely resembles the flexibility of ebuild |
| 11 |
>>> dependencies. |
| 12 |
>> |
| 13 |
>> We can borrow paludis's notion of pbins [1] to generate ebuilds which |
| 14 |
>> install pre-built content, and the generated ebuilds could have USE |
| 15 |
>> flags that behave similarly to IUSE_RUNTIME in the sense that changes to |
| 16 |
>> USE flags will result in different builds of pre-built content being |
| 17 |
>> installed. A content-hash distfiles layout [2] could serve as a |
| 18 |
>> convenient way to store separate builds of pre-built content for |
| 19 |
>> multiple combinations of USE flags, and a generated ebuild would index |
| 20 |
>> the build by USE flag combination. |
| 21 |
>> |
| 22 |
>> Also, for the generated ebuilds, we can generate USE flags to include |
| 23 |
>> separate SRC_URI downloads for pre-built content to support things like |
| 24 |
>> FEATURES=split-debug and FEATURES=install-sources. |
| 25 |
> |
| 26 |
> Note that all of this can use existing EAPI features, since everything new |
| 27 |
> would be implemented in an ebuild generator that generates a single |
| 28 |
> ebuild to index pre-built content from multiple binary package builds. |
| 29 |
> |
| 30 |
>> [1] https://paludis.exherbo.org/overview/pbins.html |
| 31 |
>> [2] https://bugs.gentoo.org/756778 |
| 32 |
> |
| 33 |
|
| 34 |
For generated ebuilds, we'll have a choice to model things as USE flags |
| 35 |
or sub-packages. For example, content from FEATURES=split-debug and |
| 36 |
FEATURES=install-sources content might make more sense to model as |
| 37 |
sub-packages than USE flags. It makes more sense to generate a |
| 38 |
sub-package when there is a need for the sub-package to have USE flags. |
| 39 |
For example, a split-debug sub-package can have USE flags which index |
| 40 |
pre-built content from builds for multiple USE flag combinations. |
| 41 |
Similar USE flags could be useful for an install-sources sub-package if |
| 42 |
the source code has patches which are conditional on USE flags. |
| 43 |
-- |
| 44 |
Thanks, |
| 45 |
Zac |
Archives