Open multiflexi opened 1 year ago
We had them back in 2020, kept it for +/- an year. The amount of users was: 1 (me).
We could keep this issue open and people could leave a reaction in the post to manifest interest.
Hey @PedroHLC is there a threshold of thumbs up to overcome to trigger the interest on building aarch64 packages in Chaotic?
I think that more important than the thumbs, is a co-maintainer to deal with those packages and routines in specific :sweat_smile:
The effort should not be limited only to those packages that are compiled by C-like languages, RUST or similar? For packages Python-based (or other scripting languages), I expect that the compatible arch
should be any
, they need only to move on an actual new directory aarch64
, right? Do you expect that the packages built by prog languages like C and RUST are a lot?
Do you expect that the packages built by prog languages like C and RUST are a lot?
https://geo-mirror.chaotic.cx/chaotic-aur/pkgs.files.txt
â•â”€pedrohlc at laptop in /tmp
╰─λ rg '\-x86_64.pkg.tar.zst$' pkgs.files.txt | wc -l
2490
â•â”€pedrohlc at laptop in /tmp
╰─λ rg '\-any.pkg.tar.zst$' pkgs.files.txt | wc -l
1414
Oh... What is creating aarch64
only for those packages tagged as any
?
Oh... What is creating
aarch64
only for those packages tagged asany
?
Did you mean "What about creating"?
I didn't give a look to the repo structure. In general I imagine that there should be a x86_64
folder containing all Chaotic AUR packages. I was thinking what about to create aarch64
folder where to copy all those 1414 any
packages (ignoring the porting of the remaining x86_64 packages) so that at least that grup of 1414 packages can be used for ARM processors.
It should be possible, wouldn't need to copy the files, relative symlinks should work, the toolbox would need to be adapted for this. After we update the x86-64 DB we will have to delete missing links, add new links, update the Aarch64 DB. But, we don't have enough manpower for this change now. (Instead of calling it a Aarch64 DB
, we could call it AnyOnly DB
)
It is a good idea. So you mean that there will be AnyOnly DB
(that will work also for other CPUs) and it keeps the original any
files, and X86_64 DB that will contain the original x86_64 only
file + symlinks from Any DB
?
It is a good idea. So you mean that there will be
AnyOnly DB
(that will work also for other CPUs) and it keeps the originalany
files, and X86_64 DB that will contain the originalx86_64 only
file + symlinks fromAny DB
?
90% right, except that the AnyDB will be the one 100% of symlinks instead of having it 50/50 which would only make our life harder.
Hi, would you consider aarch64 builds? I think it makes sense because those machines are usually quite under-powered and compilation takes forever.