On Wed, 2021-03-03 at 21:11 +1000, Allan McRae via arch-dev-public wrote: > 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: > > > 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
Well, pacman could change the behavior here and instead of simply replacing the variable and declaring one sever entry, it could take raw string, evaluate it as each $arch and save the URL for each variant. What I am proposing is to essentially split core.db into one database for each arch. So, let's say the enabled arch are any, x86_64 and x86_64-v2. Then Server = https://mirror/$repo/os/$arch would register the following DBs. https://mirror/core/os/any/core.db https://mirror/core/os/x86_64/core.db https://mirror/core/os/x86_64-v2/core.db x86_64-v2 would have precedence over x86_64, if there is a package there, it would be used, if not then x86_64 would be checked. A full port would introduce a lot of more effort into the packaging workflow. Personally, I maintain a lot of packages and would definitely be affected, this would have an heavy impact my productivity. My proposal allows me to for eg. only do arch=(x86_64 x86_64-v2) in srslte in similar packages, keeping arch=(x86_64) in the rest. Does that make sense to you? :) I think the main counterargument I see for this proposal is the splitting of databases maybe slowing down sync a bit, but honestly, do we really care about that amount of performance hit? And wouldn't that be mitigated with parallel downloads? Filipe Laíns
signature.asc
Description: This is a digitally signed message part
