glorp
glorp copied to clipboard
pharo-rdbms
Unimplemented message send in DatabaseAccessor>>#executeSQLString:binding:
At this time, we'd prefer to avoid making the download logic header-dependent (because it opens the door for doing the same for other HTTP headers, in the limit bringing the full complexity of the HTTP spec into Bazel). Can you open a feature request for Range header support at https://github.com/bazelbuild/remote-apis?
I'm also wondering why rules_apko must download individual artifacts via Range requests (which is a bit of an odd thing to do) instead of using a separate URL for each; if a rules_apko maintainer could comment here, it would help us understand how to prioritize this in the future.
I'm also wondering why rules_apko must download individual artifacts via Range requests (which is a bit of an odd thing to do) instead of using a separate URL for each; if a rules_apko maintainer could comment here, it would help us understand how to prioritize this in the future.
I'm not a rules_apko maintainer, but can comment on this. See the Alpine section of this blog post by @thesayyn from Aspect
It's necessary to use range headers when fetching packages for Linux Alpine. Per the APK format spec*, alpine packages are formatted as archives, which are always multiple gzip streams of tars combined. See the apk spec for more on the format of these binaries. This format is somewhat similar to .deb archives.
This issue is important because it essentially captures "remote downloads in bazel cannot support fetching alpine packages and .deb archives", which is a fairly major limitation.
This is a big drawback for those of us who use bazel remote execution; we're limited in how we can use bazel as a source-of-truth for hermetic builds of distroless-style lightweight base images
- for those not already familiar, apk is the package manager for alpine linux
@tjgq would it be possible to re-evaluate this issue given the info provided above? ^
Thanks for the additional context! However, I maintain my opinion that the best way forward is to add Range support to the Remote Asset API.