paru
paru copied to clipboard
Local AUR repo installs are listed twice
Affected Version
paru v1.10.0 - libalpm v13.0.1
Description
I configured that Paru should create a local AUR repository for the packages build in the chroot.
The local aur packages are not really great to distinguish from regular aur packages, except that they have a size attached to it.
It would be nice if those entries would be collapsed to one entry, as reinstalling them from the AUR isn't really an option anyway.
So 3 and 4 are actually the same package, just one is locally cached. So both should be merged together to one entry.
Number 2 is actually not installed, but number 1 is. So this "installed" is wrong - as the file was fetched from chaotic-aur and not build from the AUR package marked by Paru. Only packages which are listed by "pacman -Q --foreign" should be eligible for being displayed as installed from the "aur/*" repo, IMHO.
But that's not the case here:
# pacman -Q --foreign | grep duplicacy | wc -l
0
Output
paru.conf and pacman.conf are usually always relevant
[options]
PgpFetch
Devel
Provides
DevelSuffixes = -git -cvs -svn -bzr -darcs -always -hg -fossil
BottomUp
RemoveMake
SudoLoop
CombinedUpgrade
CleanAfter
UpgradeMenu
NewsOnUpgrade
BatchInstall
LocalRepo
Chroot = /var/lib/paru/aur_chroot
[bin]
FileManager = nnn
[options]
HoldPkg = pacman glibc
Architecture = auto
NoExtract = usr/lib/firefox/fonts/TwemojiMozilla.ttf
Color
ILoveCandy
VerbosePkgLists
DisableDownloadTimeout
ParallelDownloads = 2
SigLevel = Required DatabaseOptional
LocalFileSigLevel = Optional
[core]
Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
[community]
Include = /etc/pacman.d/mirrorlist
[multilib]
Include = /etc/pacman.d/mirrorlist
[endeavouros]
SigLevel = PackageRequired
Include = /etc/pacman.d/endeavouros-mirrorlist
[chaotic-aur]
Include = /etc/pacman.d/chaotic-mirrorlist
[aur]
SigLevel = PackageOptional DatabaseOptional
Server = file:///var/lib/paru/aur_chroot
It would be nice if those entries would be collapsed to one entry, as reinstalling them from the AUR isn't really an option anyway.
I disagree. Some times I wish to install packages from my local repo, Some times I want to rebuild the package from the aur.
Number 2 is actually not installed, but number 1 is. So this "installed" is wrong - as the file was fetched from chaotic-aur and not build from the AUR package marked by Paru. Only packages which are listed by "pacman -Q --foreign" should be eligible for being displayed as installed from the "aur/*" repo, IMHO.
Pacman does not track where stuff is installed from so it's impossible to distinguish.
You can do paru -a/--repo duplicacy
or rename your local repo to something different.
Number 2 is actually not installed, but number 1 is. So this "installed" is wrong - as the file was fetched from chaotic-aur and not build from the AUR package marked by Paru. Only packages which are listed by "pacman -Q --foreign" should be eligible for being displayed as installed from the "aur/*" repo, IMHO.
Pacman does not track where stuff is installed from so it's impossible to distinguish.
That's wrong. Pacman tracks if the package was installed from a repo or from local package files.
In my case I installed a package from the chaotic-aur repo, which means it's NOT "foreign" for pacman, but it is shown that the aur package itself is installed, which is wrong, as this would mean the package is foreign.
To track which packages were build and installed through the local aur repository vs other repositories, like the chaotic-aur, we could just fill in the "Packager" field with a value like "[chroot]paru@$machine-id" or something like that. If the machine-id is the same as the local machine we can be sure that we build it locally. :)
It would be nice if those entries would be collapsed to one entry, as reinstalling them from the AUR isn't really an option anyway.
I disagree. Some times I wish to install packages from my local repo, Some times I want to rebuild the package from the aur.
Well, if you want to rebuild it from the aur, you can just use paru -a duplicacy
, and there are only aur results. So there's nothing to merge. :)
That's wrong. Pacman tracks if the package was installed from a repo or from local package files.
No it does not.
@RubenKelevra pacman
does not do the tracking you think it does; if you have devtools
installed, try running pacman --config=/usr/share/devtools/pacman-extra.conf -Qm
and you'll see a lot more packages are considered "foreign" compared to pacman -Qm
, because /usr/share/devtools/pacman-extra.conf
won't have your local repo(s) listed in there. In fact even [multilib]
packages will be considered foreign if you use that config file.
This is probably worth closing, as I think paru
itself is working fine here and you can pick the install source (AUR vs repos) with appropriate flags.
Well in this case paru could make a list of packages it installed from the auto, combined with version and install date/time.
This would allow to filter the installed packages by this and get a list of aur packages (which were not installed manually or with a different aur helper)
Alternatively you could ship a patch to track this by pacman itself? Maybe just track if the package qas verified by a signature before installation?
Best regards
Ruben
This isn't how AUR helpers should be in the business of behaving. They should make it easier to work with packages from the AUR - and paru
specifically acts as a pacman
wrapper, so most of the flags you're used to using in pacman
simply carry over (with the exception of stuff like -a
, -c
, etc that are more relevant makepkg
or AUR-specific). Why should an AUR helper be hiding stuff from the AUR?
What you're asking for is essentially to hide stuff from the user without them making the decision to do so - that's not a good idea. If you as the user know you want to see certain sources for a package, then you are welcome to choose them for yourself using the various flags mentioned above.
Keep in mind that a local repo is at the end of the day simply a repo using the file://
protocol, neither pacman
nor paru
should be treating it in a magical way and assuming that all packages in that repo are from the AUR. For your example, chaotic-aur/duplicacy
refers to your built package in your local repo ([chaotic-aur]
) and aur/duplicacy
refers to the AUR PKGBUILD which you have to download and then build. Based on various use cases you may want to keep it up to date (i.e. you want to see the AUR package) or you may want to use the package that's already built and not rebuild it (for example, if the built package is the latest version, there's no reason for a rebuild in most cases, so you want to see the repo package in that case). paru
should not make the decision which one you can see, that's your decision as the user.
Imagine you had the same package in, say, 3 different repos (not sure how realistic/common this is, but it's absolutely technically possible). Which one should paru
show if it followed your suggestion? The program should not make such guesses on your behalf.
Instead, if you have certain use cases for yourself, you can either use the -a
or --repo
flags for paru
, or you can use custom pacman
config files which include/exclude the repos that you want, and pass those to the --config
flag of pacman
based on the use case. Running man pacman.conf
in a shell should get you started if you don't know what everything does.
Maybe just track if the package qas verified by a signature before installation?
pacman
already has this btw, not sure how that will help you though. See https://wiki.archlinux.org/title/pacman/Tips_and_tricks#Listing_packages, you should be able to change example 1.1.2.1 a bit.
Yeah not much for paru to do here.