On 4/3/21 6:38 am, Filipe Laíns wrote: > 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?
The exact same is achieved by having a "core-v2" and an "core" db, where only the x86_64-v2 optimized packages appear in "core-v2". But there would need to be two separate package pools due to name clashes. The dbscripts maintainer has already said no to this. Options realistically are: 1) bump the baseline 2) provide a second more optimized port. Allan
