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