[RFC] Ship closed-binaries in-tree and deliver them as part of the build

[RFC] Ship closed-binaries in-tree and deliver them as part of the build

[Richard Lowe]

https://code.illumos.org/c/illumos-gate/+/3445

This makes reasoning (which binaries do we use?) much easier, it also would
allow us in the future to deliver them to _different places_, should we want
to stop isaexec'ing iked, move pax to usr/has, or rearrange drivers into
/platform or /usr/kernel.

It also makes the delivery of licenses via the closed-bins (seriously,
they drop into the proto out of there) less likely to cause us to
accidentally use an older license if the build races (this  can be
fixed with the exception list, too, but as an example of what the
greater visibility brings out)

I intend this as a basis for discussion, and I think that's best done
by showing you the code and letting you look at a version that
actually works to see how this would look.  If we want to pursue this
route, I would write up an IPD that is basically a copy/paste of the
above, and a summary of the outcome of the discussion.

The makefiles are intentionally lacking framework and modularity, as
the nature of the task means that changes to them are even in the best
case, very unlikely, and they are few.

-- Rich

Re: [developer] [RFC] Ship closed-binaries in-tree and deliver them as part of the build

[Gordon Ross]

Looks like a potentially useful improvement.
What's the impact on the size of a "git clone"?

On Tue, Apr 30, 2024 at 4:49 PM Richard Lowe <richlowe@richlowe.net> wrote:
>
> https://code.illumos.org/c/illumos-gate/+/3445
>
> This makes reasoning (which binaries do we use?) much easier, it also would
> allow us in the future to deliver them to _different places_, should we want
> to stop isaexec'ing iked, move pax to usr/has, or rearrange drivers into
> /platform or /usr/kernel.
>
> It also makes the delivery of licenses via the closed-bins (seriously,
> they drop into the proto out of there) less likely to cause us to
> accidentally use an older license if the build races (this  can be
> fixed with the exception list, too, but as an example of what the
> greater visibility brings out)
>
> I intend this as a basis for discussion, and I think that's best done
> by showing you the code and letting you look at a version that
> actually works to see how this would look.  If we want to pursue this
> route, I would write up an IPD that is basically a copy/paste of the
> above, and a summary of the outcome of the discussion.
>
> The makefiles are intentionally lacking framework and modularity, as
> the nature of the task means that changes to them are even in the best
> case, very unlikely, and they are few.
>
> -- Rich
>
> ------------------------------------------
> illumos: illumos-developer
> Permalink: https://illumos.topicbox.com/groups/developer/Tb64944d83604d344-M27ba9d393d6dd856fea170a0
> Delivery options: https://illumos.topicbox.com/groups/developer/subscription

Re: [developer] [RFC] Ship closed-binaries in-tree and deliver them as part of the build

[Peter Tribble]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On Tue, Apr 30, 2024 at 9:49 PM Richard Lowe <richlowe@richlowe.net> wrote:

> https://code.illumos.org/c/illumos-gate/+/3445
>
> This makes reasoning (which binaries do we use?) much easier, it also would
> allow us in the future to deliver them to _different places_, should we
> want
> to stop isaexec'ing iked, move pax to usr/has, or rearrange drivers into
> /platform or /usr/kernel.
>

I like it. Just one question for clarification/confirmation:

The current layout assumes a single architecture (actual binaries are in
architecture
subdirectories, but other files aren't), so we would never ever use this
for any future port?


> It also makes the delivery of licenses via the closed-bins (seriously,
> they drop into the proto out of there) less likely to cause us to
> accidentally use an older license if the build races (this  can be
> fixed with the exception list, too, but as an example of what the
> greater visibility brings out)
>
> I intend this as a basis for discussion, and I think that's best done
> by showing you the code and letting you look at a version that
> actually works to see how this would look.  If we want to pursue this
> route, I would write up an IPD that is basically a copy/paste of the
> above, and a summary of the outcome of the discussion.
>
> The makefiles are intentionally lacking framework and modularity, as
> the nature of the task means that changes to them are even in the best
> case, very unlikely, and they are few.
>
> -- Rich
>
> ------------------------------------------
> illumos: illumos-developer
> Permalink:
> https://illumos.topicbox.com/groups/developer/Tb64944d83604d344-M27ba9d393d6dd856fea170a0
> Delivery options:
> https://illumos.topicbox.com/groups/developer/subscription
>


-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

[-- Attachment #2: Type: text/html, Size: 3000 bytes --]

Re: [developer] [RFC] Ship closed-binaries in-tree and deliver them as part of the build

[Richard Lowe]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

Except perhaps s390 and sparc., I don't think there's a source of
binaries.  The files that aren't mach-specific are common across them.

mach-specific files just need the directory (and makefiles for new bits).

[-- Attachment #2: Type: text/html, Size: 294 bytes --]

Re: [developer] [RFC] Ship closed-binaries in-tree and deliver them as part of the build

[Richard Lowe]

[-- Attachment #1: Type: text/plain, Size: 134 bytes --]

It's about 20M, but it's possible the final change would be to structure
the illumos/closed repo this way, rather than inlining it.

[-- Attachment #2: Type: text/html, Size: 163 bytes --]