| 1 |
On Thu, Jan 20, 2022 at 4:10 PM Piotr Karbowski <slashbeast@g.o> wrote: |
| 2 |
> |
| 3 |
> Ideally we'd have some way to mark binary packages with new EAPI and |
| 4 |
> have FEATURES flag like 'prefer-binary' and go with -bin in case there's |
| 5 |
> || ( ) dependencies list, regardless of the original order in virtual. |
| 6 |
> This way everyone could be happy and not choose one workflow over another. |
| 7 |
|
| 8 |
Ideally we'd just have a repository of binary builds for everything |
| 9 |
with default USE flags for a few profiles, and users could choose to |
| 10 |
configure portage to just download the binary package if the flags |
| 11 |
match, and of course this could be overridden per-package. Then there |
| 12 |
would be no need for -bin anything. We have to maintain half of that |
| 13 |
for the stage builds anyway. |
| 14 |
|
| 15 |
I don't have a strong preference but I doubt that many of our users |
| 16 |
receive any benefit whatsoever from building rust from source, and so |
| 17 |
I'd suggest -bin ought to be the default. However, having a |
| 18 |
pre-installation notice that the -bin is available with a link/etc to |
| 19 |
how to use it seems reasonable. I bet a lot of users spend more time |
| 20 |
getting the source build to work than it would take to just |
| 21 |
reconfigure things so that they get the -bin. If users are building |
| 22 |
in a tmpfs or with numerous parallel jobs odds are that they'll end up |
| 23 |
with a build failure for rust - CPU cores are way cheaper than RAM. |
| 24 |
|
| 25 |
-- |
| 26 |
Rich |
Archives