On 3/3/21 9:00 pm, Filipe Laíns wrote: > On Wed, 2021-03-03 at 20:52 +1000, Allan McRae via arch-dev-public wrote: >> 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 > > We are already rewriting dbscripts for the git migration anyway, so I think > it's > worth exploring. > Why would the mirror URLs be an issue if we are using $arch as a placeholder? > > Sorry if I wasn't clear, but I meant that we would have a partial port! pacman > would download all the DBs for the supported archs, hence my question about > the > DBs. It would look at x86_64-v2 first and if the package wasn't there, it > would > then look at x86_64. Makes sense? > This could cause some breakage, but we work around that. >
The mirror in our mirrorlist file use "$arch" which pacman replaces with the architecture of what it needs to download. Without a complete port, that value would remain as x86_64. So now you need to put each mirror in the mirrorlist file twice (one with x86_64-v2 and one with x86_64), and you would have to assume they stayed in sync or risk partial updates. I think a partial port would require more effort in the long run than a complete one. And if we can do x86_64-v2, we might as well do -v3 too. Allan
