Repository navigation
Feat: let chisel fetch DEBs for the same architecture as the underlying execution environment #11
Description
At the moment, only amd64 seems to be supported.
Steps to reproduce
(if emulation is needed, simply run the following with docker buildx for ease of use. Example docker buildx build --platform=linux/arm64 . --progress plain)
Run on any arch different from amd64:
chisel cut --release ubuntu-22.04 --root /tmp openssl_config
Output:
#8 0.142 2022/07/01 15:45:42 Consulting release repository...
#8 0.413 2022/07/01 15:45:43 Fetching current ubuntu-22.04 release...
#8 0.416 2022/07/01 15:45:43 Processing ubuntu-22.04 release...
#8 0.431 2022/07/01 15:45:43 Selecting slices...
#8 0.431 2022/07/01 15:45:43 Fetching ubuntu 22.04 archive details...
#8 1.171 2022/07/01 15:45:44 Release date: Thu, 21 Apr 2022 17:16:08 UTC
#8 1.171 2022/07/01 15:45:44 Fetching ubuntu 22.04 main component...
#8 1.628 2022/07/01 15:45:44 Fetching ubuntu 22.04 universe component...
#8 4.639 2022/07/01 15:45:47 Fetching pool/main/o/openssl/openssl_3.0.2-0ubuntu1_amd64.deb...
#8 5.210 2022/07/01 15:45:48 Extracting files from package "openssl"...
Notice the line
#8 4.639 2022/07/01 15:45:47 Fetching pool/main/o/openssl/openssl_3.0.2-0ubuntu1_amd64.deb...
Proposed solution
Before defining the archives, infer the underlying architecture instead of defaulting to amd64.
NOTE: this was already planned at
Line 89 in c3c14e5
Questions
- do we need to define Slice Definition Files / package / architecture? Or can we just have one Slice Definition File per package (as we do right now, for each release), and somehow have a new directive to let us identify contents which are architecture specific?
Activity
woky commentedon Jul 4, 2022
Adding to what @cjdcordeiro said above. In the PR we have a PoC for multi-arch chisel, but that leaves some problems on the table.
Consider
libc6and following arches: amd64 arm64 armhf i386 ppc64el riscv64 s390xBelow is a listing of contents of the library for all the architectures mentioned above (Note that I removed
gconvand/usr/sharedirectories. We don't care about those. At least not now.):Details
Immediate difference in paths between architectures is
/lib/*-linux-*. This commit shows howlibc6slices can be updated to account for some path differences: woky/chisel-releases@c59d9e8?diff=split With this commit and this piece of shell, I can slicelibc6_libsfor all arches:However, note that I had to comment out
/lib/*-linux-*/libmvec.so.*because it doesn't exists for some architectures.Also, there are major differences in dynamic linker/loader symlinks (those outside of
/lib/*-linux-*/):I can match all of them with the wildcard
/lib*/ld*.so.*but it seems too general. It might work forlibc6, but for other packages, we could match unintended files.So the question in addition to the previous post is, how should we handle multi-architecture slices?
/cc @cjdcordeiro @niemeyer
cjdcordeiro commentedon Jul 4, 2022
thanks for the example @woky . I also agree that the usage of "*" seems a bit abusive in this case.
niemeyer commentedon Jul 5, 2022
Let's get something nice in place to solve this. What's the urgency here?
cjdcordeiro commentedon Jul 5, 2022
it depends on whether @woky can make the current SDFs in https://github.com/woky/chisel-releases/tree/ubuntu-22.10-dotnet6/slices work for multi-arch (with the "*" workaround). @woky?
If not doable, then I'd say this should be addressed as soon as possible.
woky commentedon Jul 5, 2022
@cjdcordeiro @niemeyer I think the
libc6is the ugliest case but I can make it work with the wildcards above. I also need to find out which are the architectures that don't contain/lib/*-linux-*/libmvec.so.*and check .NET works without it. We only needamd64andarm64right now, so if it's in both, it's fine.cjdcordeiro commentedon Jul 5, 2022
thanks @woky . even if it works, I'd recommend we play it safe and try to address this without too much delay. I don't think we need to rush, but it would probably be nice to make it the next priority item for
chisel. Just to kick things off, I'm capturing here the few thoughts I had on this matter:What if we have just one Slice Definition File (SDF) per pkg, which encompasses all DEB contents for all the pkg architectures? Something like
Concern: mutation scripts could potentially start having a lot of conditionals for mutating the right files for the right architectures. Would it make sense to create yet another directive for creating content aliases? Example: