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. Filipe Laíns
signature.asc
Description: This is a digitally signed message part
