Merging independent package lists to a single package list

[marcel]

Currently we are maintaining 3 different package lists for the mirroring project:

• All list - listing packages to be mirrored for all achitectures
• amd64 list - listing packages to be added for the amd64 architecture
• arm64 list - listring packages to be added for the arm64 architecture

It has been considered a bit cumbersome to maintain and cause for confusion in the past. The proposal would be to merge everything into a single list and fetch all the binary packages for all supported architectures instead. Today being arm64 and amd64.

Initial testing shows this will only fetch 142 extra binary packages for arm64 at the time of writing.

Any thoughts or comments on this?

[xzhang1]

For aria:main, currently we have 4300+ source packages and they contains 28000+ binary packages. While with this merge, only 140+ binary packages. The total size of those 142 binary packages is only about 220 MB.

[marcel]

One thing I forgot to ask in the original topic, is if we see any functional reason for not merging this, that I might have missed.

What was the initial reason for splitting this? Maybe @markawr has some historic perspectives here that I am not aware of.

[lyang0]

We don’t include all Debian packages in eLxr - we maintain a restricted, curated support list. If we use a single package list and sync everything to both architectures, we might accidentally make Package A available on arm64 when we only intended to support it on amd64. This could mislead users into thinking we officially support that package on arm64 when we don’t.

[marcel]

@lyang0

This could mislead users into thinking we officially support that package on arm64 when we don’t.

In what sense do you mean support the package? In the mirroring project we mirror packages directly from Debian.

These are not packages we maintain ourselves for eLxr. In that sense we don’t really maintain them within the eLxr project?

[markawr]

Unlike how the code behaves now where the list includes a source package and all derived packages will be mirrored the original code mirrored specific packages included in each list. In this way a package might exist in amd64 and not in arm64, in this case it was added to the arch specific list, otherwise it was in the generic list. The idea was to avoid attempting to mirror a amd64 package from the arm64 runner which would generate an error.