Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Architecture specific Packages file lacks arch all packages #22

Open
agx opened this issue Apr 22, 2023 · 2 comments
Open

Architecture specific Packages file lacks arch all packages #22

agx opened this issue Apr 22, 2023 · 2 comments

Comments

@agx
Copy link

agx commented Apr 22, 2023

This breaks deboostrap as it only looks at that file to figure out the Priority: required packages, e.g.

dak/debian (has $arch and all in that single file):

$ curl  https://deb.debian.org/debian/dists/bookworm/main/binary-amd64/Packages.xz 2>/dev/null | unxz - | grep -qs "Package: debconf$" && echo "Package debconf found" || echo "Package debconf not found"
Package debconf found

but laniakea only $arch:

$ curl http://repo.scratch.pureos.net/pureos/dists/crimson/main/binary-amd64/Packages.xz 2>/dev/null | unxz - | grep -qs "Package: debconf$" && echo "Package debconf found" || echo "Package debconf not found"
Package debconf not found

It is in the architecture all file though:

$ curl http://repo.scratch.pureos.net/pureos/dists/crimson/main/binary-all/Packages.xz 2>/dev/null | unxz - | grep -qs "Package: debconf$" && echo "Package debconf found" || echo "Package debconf not found"
Package debconf found

but that's not enough to make deboostrap happy.

Would be great if laniakea would mimic what Debian does here so debootstrap can work.

@ximion
Copy link
Member

ximion commented Apr 23, 2023

Oh, this is an interesting one!
So, Laniakea implements a new-style APT archive, where arch:all is not included in arch:any indices. This simplifies computation a lot and is also very space-efficient. It is also fully supported by Debian, however Debian also still includes a compatibility fallback, while on Laniakea I did not implement that (because it's a lot of work to make something worse ^^).

From https://wiki.debian.org/DebianRepository/Format#No-Support-for-Architecture-all:

Architectures: [...] The presents of the architecture all in this field indicates that the architecture-specific indexes do not include information about Architecture:all packages and have instead their own index file with the architecture all. Clients must download the all index files in this case, but must not download them if the Architectures field does not include all.

No-Support-for-Architecture-all
An optional field with a temporary and very specific usecase: Servers who already support and distribute indexes for the architecture all, but still include their content in the architecture-specific indexes as well can use this field to exclude certain indexes from the handling defined in the Architectures field. Clients should support the value Packages, which excludes the Packages indexes from this handling. If they don't support it they will download needlessly duplicated data, which they have to deal with correctly.

The field's purpose is to decouple the introduction of indexes like Contents-all from the introduction of Packages-all. Support by clients (if they choose to support it at all) is therefore bound to disappear after the transition to all for all indexes is done.

Given that, I think Laniakea implements this correctly: It does not set No-Support-for-Architecture-all and it includes all in the architectures list of the repo data.

So, we have two options here, assuming there isn't a bug I missed and Laniakea is implementing this according to spec (which I think it is): Either implement the legacy-style archive support in Laniakea, or teach debootstrap how to deal with the modern archive layout.

I do strongly prefer the latter, because I think it will help Debian in the long run as well when they eventually switch archive layouts, and it prevents extra work in Laniakea that we will have to test and will eventually deprecated and remove again anyway.
But I'm open to feedback (and also haven't yet looked into how easy this would be to implement in Debootstrap, I wasn't aware that the tool had problems with this layout).

@agx
Copy link
Author

agx commented Apr 23, 2023

I'd really prefer to have it compatible with the Debian archive. debootstrap is so ubiquitous that not having it makes bootstrapping crimson really cumbersome (and we're already pretty late on that one). Once debootstrap is fixed and at least in a stable Debian release support could be dropped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants