Repository navigation
Add support for architecture variants - #1638
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1638 +/- ##
==========================================
- Coverage 77.81% 77.62% -0.19%
==========================================
Files 165 165
Lines 16125 16141 +16
==========================================
- Hits 12548 12530 -18
- Misses 2363 2401 +38
+ Partials 1214 1210 -4 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
e6efb13 to
9967404
Compare
|
rebased on master |
9967404 to
2818aeb
Compare
|
I tested the rebased PR using the official CI-built Noble/amd64 artifact: aptly version: 1.6.3+20261101095331.89eee947 The test was performed with our real Ubuntu 26.04 (Resolute) mirror setup. The complete mirror workflow succeeded for: with all four components: and with both amd64 and amd64v3. Our normal production-like workflow completed successfully, including mirror updates, snapshot creation, publish switches, security promotion and snapshot retention. I also tested the resulting repository with a real Ubuntu 26.04 client. With: APT::Architecture-Variants "amd64v3"; APT fetched the amd64v3 package indexes and successfully upgraded 85 real packages from the published repository, including packages such as systemd, SSSD, snapd, PipeWire and GNOME components. The downloaded packages were the expected _amd64v3.deb variants. I also verified that the publish contains the regular and variant package independently. For example, the same systemd version is published as: binary-amd64: systemd_259.9-0ubuntu0.1_amd64.deb and binary-amd64v3: systemd_259.9-0ubuntu0.1_amd64v3.deb with Architecture-Variant: amd64v3. Finally, I disabled APT::Architecture-Variants on the client, refreshed the package lists and verified that APT fetched only the regular amd64 indexes and selected: systemd_259.9-0ubuntu0.1_amd64.deb So both the architecture-variant path and the normal amd64 fallback work as expected with the rebased CI build. No issues found in these tests. |
2818aeb to
faa348f
Compare
|
rebased on master |
|
Hi @hjmitsd ! Awesome work 👍 We should add some system tests, I would like to see a real mirror being mirrors with arch variants... Could you try to add some system tests ? They should just download a handful of packages, in order to be fast (not the whole I will then mirror those packages on repo.aptly.info for the pipeline tests to not depend on changing public repos. |
faa348f to
eb76598
Compare
|
force pushed to fix rebase typo |
eb76598 to
c6a9cc1
Compare
|
I have a small system test working locally against the Ubuntu Resolute archive. It mirrors only one package ( The two package files are: The test currently uses: class UpdateMirror29Test(BaseTest):
"""
update mirrors: architecture variants
"""
sortOutput = True
longTest = False
fixtureCmds = [
"aptly mirror create --ignore-signatures "
"-architectures=amd64,amd64v3 "
"-filter='Name (3cpio)' "
"arch-variant https://archive.ubuntu.com/ubuntu/ resolute main",
]
runCmd = "aptly mirror update --ignore-signatures arch-variant"
def check(self):
self.check_output()
self.check_cmd_output(
"aptly mirror search -format='{{.ShortKey}}' "
"arch-variant 'Name (3cpio)'",
"packages",
)It downloads only the two packages (~0.54 MiB total), and afterwards verifies that both package identities are present independently: The system test passes locally both when capturing the golden files and on a clean rerun without capture. I have not pushed it yet, so I can switch it directly to the |
|
I would need to have the logs "Downloading.." from the test in order to create the test mirror. you can push the test as is, or send me the url list :) |
|
uploaded: |
c6a9cc1 to
54fba1c
Compare
|
renased on master and fixed conflict in deb/list.go by keeping master's grouping approach (which handles invalid versions correctly) and using IndexArchitecture() as the key instead of p.Architecture. |
54fba1c to
b89f92e
Compare
b89f92e to
972cf0b
Compare
|
@hjmitsd great, we have a system test :) |
Fixes: #793, #1468
Discussion / Request: #1501
Summary
This PR adds support for package architecture variants such as
amd64v3.Ubuntu 26.04 publishes separate indexes such as:
while packages from the variant index still use:
This means a regular package and its architecture variant may have the same name, version and base architecture. Aptly currently treats them as the same package identity.
Approach
The patch introduces the concept of an index architecture:
amd64amd64v3The original
Architecture: amd64remains unchanged and continues to be used for dependency matching.Architecture variants are distinguished only where package or repository identity requires it.
The changes cover:
-force-replaceExisting packages without
Architecture-Variantretain their previous package keys and behavior.Validation
The implementation was tested with both automated tests and real Ubuntu 26.04 repositories.
A full Ubuntu 26.04 mirror was created for release, updates, security and backports, including
main,universe,restrictedandmultiverse, with bothamd64andamd64v3.A real Ubuntu 26.04 APT client successfully selected and installed the
amd64v3package when configured with:I also tested an in-place upgrade of an existing Aptly mirror database populated by unmodified upstream Aptly. The patched build added the previously discarded
amd64v3packages without requiring a mirror rebuild.The relevant test suites pass:
The remaining failures from
go test ./...are reproducible on the unmodified upstream source and are unrelated to this change.Additional upstream issues
Two pre-existing issues were found during development and are included as separate commits:
maximumVersion=1could collapse packages from different architectures.Both also affect ordinary non-variant packages.
I can split these into separate PRs if preferred.
Development process
For transparency, I developed this implementation with assistance from OpenAI Codex.
The resulting changes were reviewed and validated with regression tests, real Ubuntu 26.04 repositories, an existing Aptly database and a real APT client.
This is my first contribution to Aptly, so I am happy to adjust the implementation, naming, scope or commit structure to better match the project's conventions.