Some packages install in under a minute, while alternatives which seem functionally similar, take hours.
Sometimes there are several available options to fit a use case and I would like to use it now. Is it possible to anticipate which one will likely be the fastest to get rolling?
Generally I like to install via yay.
Searching around here is what I learned. Agree?:
- AUR will be slower
- Certain categories of package, like web browser, are inherently slow
- Selecting
-binwill be faster if available
Is there some way to guess beyond that? Certain programing languages take longer than others? Is it in relationship to existing packages on the system? Other characteristic? Some kind of dry-run feature to estimate?
Obviously I don’t have the fastest computer. I have added MAKEFLAGS="-j4" to /etc/makepkg.conf so at least all 4 cores can get used.
Once I realize a package is going to take ages to get ready, is it possible to safely intervene to stop the process? I try to avoid it because in general I understand arch-based distros don’t like “partial” installs. But is it safe to stop compiling? No changes have yet been made, right?
It depends on many things. The webbrowser thing is just because of the size of the package.
AUR is not necessarily slower. It depends on if you have to compile it or not, size of build dependencies…
There are too many variables.
If you install AUR things with
yayorparu… It’s pretty safe to justCtrl+Conce. It should clean everything up.In any case, yes, the
*-binpackages generally are pre-compiled, so someone else has done the effort already, so your install is just way faster.In my experience larger packages (in terms of file space requirements) install slower, but download speed is a factor there too.
Cancelling compilation is safe to my knowledge. No changes were made as you stated. Just remember that the downloaded files will probably still be in your cache afterwards, so you may want to remove that with paccache.
You mention “partial installs,” but the actual issue is partial upgrades. A partial upgrade is when you don’t upgrade the entire system, but only one or more packages. A partial install isn’t really a term people use, but could probably refer to installing a package without its dependencies being installed.
Ya you’re right I am thinking “partial upgrade”; I just thought the concept might generalize.
I guess the worst that could happen with a partial install would be some deps installed in the system but then not actually required.
The biggest difference will be between binary packages and packages that compile from source. Yes, big binary packages like browsers take longer but it really doesn’t take that long. You should be able to quit the compilation without problems. Only after the compilation is done will the package manager be invoked to install the resulting binary.
Once I realize a package is going to take ages to get ready, is it possible to safely intervene to stop the process? I try to avoid it because in general I understand arch-based distros don’t like “partial” installs. But is it safe to stop compiling? No changes have yet been made, right?
AUR helper do that user friendly, just cancel the process with CTRL-C
the package gets installed only at the END of the compilationcompiling manually (no PKGBUILD or AUR helper) will be different, especially if don’t build a package first
things likemake installusually don’t and can leave a messMy biggest issue with YAY is the occasional mandatory compiling of an app seemingly randomly, so I go in thinking a quick update will turn into a much slower one because of the compiling it does. I haven’t looked into it, but if there was a way to alert before doing this via a flag, it’d save me time and sometimes frustration.
I have learned over the years to try to install the -bin version as much as possible, but sometimes that’s not enough if flagged out of date (Joplin especially), so I sometimes end up installing the appimage.
