You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to @waddlesplash, "any" architecture packages are built for all architectures separately. This is redundant and wastes resources. "any" arch packages are meant to be suitable for "any" architecture, therefore they need to be built only once (e.g. on x86_64) and then resulting packages can be reused for all architecture specific repositories, e.g. by making symlinks on the server side.
This was discussed in the context of the texlive package (see haikuports/haikuports#6771), which is > 4GB in total and would therefore benefit massively from this. When there are more than 2 supported architectures in the future, the benefits would be even greater.
The text was updated successfully, but these errors were encountered:
Would fixing this require having a buildmaster only for the "any" "architecture"?
Or maybe just disabling "any" arch for all but one buildmaster?
In either case... I guess we would end up needing a central https://eu.hpkg.haiku-os.org/haikuports/r1beta4/any/current repo setup, and it added to the default list of repositories on Haiku images/.hpkg, no?
Sounds like we need coordination with the sys-admin team on this one (besides any needed changes on HaikuPorter/Haiku).
According to @waddlesplash, "any" architecture packages are built for all architectures separately. This is redundant and wastes resources. "any" arch packages are meant to be suitable for "any" architecture, therefore they need to be built only once (e.g. on x86_64) and then resulting packages can be reused for all architecture specific repositories, e.g. by making symlinks on the server side.
This was discussed in the context of the texlive package (see haikuports/haikuports#6771), which is > 4GB in total and would therefore benefit massively from this. When there are more than 2 supported architectures in the future, the benefits would be even greater.
The text was updated successfully, but these errors were encountered: