I have built a recent version of Emacs with my own configuration preferences and build settings. I have also installed the package mu(as in mu4e) from the AUR, which lists Emacs as a dependency.
I’ve symlinked my version of Emacs to /usr/bin/emacs, but of course it is not registered in my local package database (e.g. doing pamac list -i | grep emacs outputs nothing).
This wouldn’t normally trouble me, but it seems as though I can’t update mu without installing a version of Emacs from the Manjaro repositories, or registering my local version of Emacs in the package database.
I think the latter is the course of action I would prefer to follow, but I want to check if there was any suggested way to do so.
It’s not clear to me that pamac has this functionality, e.g. see the accepted answer in this forum post
From the Arch Wiki page for pacman, the relevant commands seem to be:
pacman -Upacman - ArchWiki
but it seems like I would have to create a .pkg.tar.zst file for my package
pacman -D --asdepspacman - ArchWiki
which seems more appropriate, but I’m not 100% sure.
While I’d appreciate a solution that’s specific to this example (i.e. upgrading mu while keeping my local version of Emacs), I’m more interested in how I would register a locally built package and if there is a preferred way of doing so in Manjaro.
To be able to have a custom version - copy the PKGBUILD from Arch - modify accordingly - like you would with an AUR custom script.
Ensure you pkgrel is bigger than package in the repo - it would be better to rename the package e.g. emacs-custom and make it conflict with emacs and providing emacs.
This would ensure you always use your own package and mu (mu4e) dependency would be satisfied.
Thanks. I haven’t “built a package” in this official way before – all the ones I’ve built “by hand” in the past have been one-offs that I’ve been able to keep isolated from the rest of the system (e.g. they weren’t dependencies for anything else).
I’ll probably wait until Emacs 29.2 or 30 releases rather than rebuild my current version, so I think I’ll follow your quick solution for now, but:
If I call my current local package emacs-taylors-version and make the barebones PKGBUILD file as you say (then doing makepkg -i or pacman -U emacs-taylors-version.pkg.tar.zst), when I get round to Emacs 30, I can write a proper PKGBUILD (with all the compiler flags etc.) for emacs-taylors-version and invoke makepkg and have my local version updated appropriately, right?
That is the worst thing you can do - compiling and installing “by hand” like we are 25 years in the past. And even by hand, if done properly eg. everything is where it has to be, linker knows where stuff is etc, it should work. Files aren’t conscious to know who put them there.
So this suggests that your compiled thing is in some non-standard place.
The main reason for using package manager is that, as the name suggests, it manages all packages – and files. And for example, it’s dead simple to remove them when necessary.
Huh? Does it have a phone? PKGBUILD doesn’t have anything to do with what you compiled yourself already.
Well, you can’t do pacman -U until you have a .tar.zst for which you have to run makepkg first.
Check AUR, there is emacs-git, which is v30+ or repo version and modify whatever is easier.
No. If you have your emacs files in the same path as the package, you will get ‘exists in the filesystem’ error. So you have to remove those files first. Or overwrite them - but then again, are you sure all got overwritten or was some stuff left behind from your manual install (another reason for using package manager).
Other than that, just read archwiki on makepkg and PKGBUILD. Basically it’s nothing more than a bash script where you put the same compilation steps as you would do by hand, only that here you install them in fake folders that correspond to real ones and put everything in a .tar.zst package so then pacman can just open that and extract. (Check few PKGBUILDs, and open some .tar.zst packages and you’ll see.)
$ man makepkg
[...]
-s, --syncdeps
Install missing dependencies using pacman. When build-time or run-time dependencies are not found, pacman will try to resolve them. If successful, the missing packages
will be downloaded and installed.
-r, --rmdeps
Upon successful build, remove any dependencies installed by makepkg during dependency auto-resolution and installation when using -s.
-i, --install
Install or upgrade the package after a successful build using pacman(8).
-c, --clean
Clean up leftover work files and directories after a successful build.
[...]
(the s is one that thats most helpful, but often not included - it will get the dependencies as well)
And even by hand, if done properly eg. everything is where it has to be, linker knows where stuff is etc, it should work. Files aren’t conscious to know who put them there.