On Wed, 2021-03-03 at 19:44 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 7:31 pm, Filipe Laíns wrote:
On Wed, 2021-03-03 at 12:12 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:56 am, Filipe Laíns wrote:
On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote:
On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote:
I wonder, might this be an interesting time to reintroduce multiple architectures?
We used to offer i686 and x86_64.
Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4.
That is a possibility that has been discussed over the years. It was previously decided that we needed other architecture builds to be automated, and thus automated package signing. This becomes a possibility once we manage to sign databases (which will hit a decade of pacman support in October!).
Allan
Is it possible to get pacman to allow us to enable multiple architectures at once and prioritize one of them? This way we could just do x86_64 and the maintainer could opt-in into x86_64-* if it makes sense for the package.
This would not introduce new effort to maintainers and would solve the issue quite nicely IMO.
No it is not possible in pacman (without abusing fall through when failing to download a package from a server).
Well, can we add it? What are the technical limitations here? I vaguely remember that package names colliding in the DB could be an issue, is there any way we can solve that? Do you have any suggestions on how this could be fixed?
You would create "core-x86_64-v2" and "extra-x86_64-v2" repos that could be enabled above the current ones. That would involve downloading twice the repos and figuring out our package pool (as you can not do that with different architecture strings). Cleaner to have two separate architecture builds.
Allan
That is a reasonable enough approach, I think, though not optimal. I agree that it would be better to have separate architecture builds. I'd also really like to have this handled automatically by pacman, instead of having user having to manually enable it. Is there nothing we can do to fix the collision in the DB? Right now, the DB is located at https://mirror/core/os/x86_64/core.db Perhaps this does not make that much sense, but what about splitting the arch DBs? https://mirror/core/os/{any,x86_64,x86_64-v2,...}/code.db Does downloading the same data split across a few DBs take that much time? And wouldn't this be mitigated by parallel downloads? This is just me spit-balling... Filipe Laíns