On 3/3/21 8:32 pm, Filipe Laíns wrote: > 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... >
I'd hate to be the dbscripts maintainer who implements that! Also, $arch in mirror URLs would likely have issues, as it would need be x86_64 unless there was a complete x86_64-v2 build. I think a partial x86_64-v2 port would be more effort than having a full one. Allan
