paru icon indicating copy to clipboard operation
paru copied to clipboard

Local AUR repo installs are listed twice

Open RubenKelevra opened this issue 2 years ago • 4 comments

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

Screenshot_20220418_153824

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

RubenKelevra avatar Apr 18 '22 13:04 RubenKelevra

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.

Morganamilo avatar Apr 18 '22 17:04 Morganamilo

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. :)

RubenKelevra avatar Apr 18 '22 20:04 RubenKelevra

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. :)

RubenKelevra avatar Apr 18 '22 20:04 RubenKelevra

That's wrong. Pacman tracks if the package was installed from a repo or from local package files.

No it does not.

Morganamilo avatar Apr 18 '22 20:04 Morganamilo

@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.

eclairevoyant avatar Oct 25 '22 18:10 eclairevoyant

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

RubenKelevra avatar Oct 26 '22 05:10 RubenKelevra

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.

eclairevoyant avatar Oct 26 '22 05:10 eclairevoyant

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.

eclairevoyant avatar Oct 26 '22 05:10 eclairevoyant

Yeah not much for paru to do here.

Morganamilo avatar Nov 12 '22 16:11 Morganamilo