Pamac 11.5.2-2 ignores IgnorePkg in pacman.conf completely

FYI if like me you want to track progress in gitlab, there is a fix is linked to issue 1334 : Pamac indicates and chooses update of package that is on ignore list (#1334) · Issues · Applications / pamac · GitLab
Hasn’t yet made it into a released package version.

Thanks @philm for the earlier post which helped me figure out where to look.

We pushed new pamac packages to all branches. Pls test.

Seems to be working as intended now on my side, my ignored AUR packages are ignored.

In my opinion - one app writing to another apps config - is confusing at best - bad practise at worst.

When pamac is instructed to ignore packages - it should do so in it’s own config and thus not involve the native package manager.

One app should never change another apps configuration - it will lead to confusion - especially in situations like this where pacman natively ignores anything not in the databases.

This leads to an expectation that when you use pacman -Syu - with an ignorepkg - e.g. postman-bin (which is a custom package) - which then would lead to pacman failure when it cannot find the package in the repos.

Again this is a personal opinion - it is a very bad practise to write another apps config - this should only be done by the user - and the argument against this practise is - that it may create weird issues, which then again may be reported upstream to the developer(s) of the app, which then are completely in the dark, why that issue even is an issue.

Bad practise should never be an issue with software.

1 Like

I think having multiple places to add ignored packages is confusing.

You have a point - nevertheless - you should expect the app in question to handle it on it’s own - not configure a second app to follow suit.

It is like me saying to you - I only drink coffee - you cannot have tea anymore.

There is other methods to get that info without actually updating.

The script could even be amended to implement an ignorelist - as you have a requirement for - in fact I just did as I realized I would benefit myself :slight_smile:

If AUR would be officially supported by manjaro this argument would hold. But as it is not, this merging of AUR and pacman into one config file blurs the line even further than only offering AUR in the officially supported pamac app.

$ man pamac
...
DESCRIPTION
       pamac is a libalpm(3) front-end with AUR support.

Does this no longer hold true? Or are we debating what support means?

1 Like

Yes we are, they provide a tool for you to manage AUR on your own, but manjaro does not support issues you have with it.

Issues you have with manjaro packages you can expect to get support to. With AUR, you can only expect community support.

1 Like

I think you are misunderstanding. Pamac supports AUR, it is intended to be an AUR helper. The fact that Manjaro team doesn’t want to hear about AUR issues doesn’t mean that Pamac development should be altered and AUR shouldn’t be an important feature of Pamac.
Pamac reads the config from pacman.conf file for the ignored packages/groups, it makes sense that if you want the list modified it modifies it in this config file, or else you end up with different config files not supported by all applications and then you need to add same ignored packages/group list to different applications. That makes no sense to me.

no, you add AUR package ignore to pamac config file, and supported packages to pacman config file. This would be logical. As it is now it is “simplified” to have only one place to add them to, but as linux-aarhus said it is not correct. And what i said is that it is most certainly not correct as long as you try to maintain “AUR is not officially supported” even when your by-default provided program uses the config file of the official package manager to make these changes.

While I can understand why Pamac writes the IgnorePkg to pacman.conf as this will ensure consistency in the behavior for the given function and I can live with that but in my opinion

  • adding custom build scripts to pacman.conf in the IgnorePkg has no place
  • that sort of configuration should be kept in pamac.conf where Pamac can do what need be

We should be thankful to the upstream Arch developers that has made pacman smart enough as to consult the package database when checking IgnorePkg and silently ignore.

1 Like

OK I could agree that for only AUR packages it could be added to pamac.conf, but that doesn’t change the fact it needs to read and write to the pacman.conf file for the repo packages.

But now I wonder in this case if a package is installed from AUR, added to ignored packages in pamac.conf and not pacman.conf, and is also available in repositories too, wouldn’t Pacman try to update it from repositories then? I know Pamac has this behavior, the other way around, when a package installed from repos is only available in AUR, then it switches it to the AUR version.

Same here. It still correctly ignores WINE holding back to my 8.1 install, but not these:

gimp-gt
dosbox-x
python-2
and a KwinFT wrapper.

Needs fixed! I do not want to have to manually ignore these when it was working fine before.

But it shouldnt. Especially with the talk of ‘leaving pacman behind and only using pamac’ … then pamac should cease relying on pacman functionalities, and cease interacting/augmenting other tools in an erratic way.
pamac should have its own functionality for this, not hijack another forntend.
And this goes for other things too … like the shared /var/cache/pacman/pkg directory.

So in your opinion, if you exclude packages from Pacman, and then use Pamac, it should update the ignored packages in Pacman? Or if you ignore packages from Pamac, then update using Pacman, Pacman should update these package? I see your point of view, but practically that makes no sense to me.

First, I dont see any other way unless we expect pamac to simply not have the function, so in order to ignore packages users would need to additionally install pacman … and then at all times remember to check its conf even if they never use the software and otherwise only interact with pamac conf?
Personally I find that less intelligible to random user X.
Second from a ‘sysadmin’ point of view … they are different tools. They might have similar uses … but I dont expect my cookie settings in firefox to be automatically mirrored in chromium. And I dont think I would enjoy a system where that is the case.
There may be room for compromise though… for example - a documented check for a pacman installation, and if one exists, absorb its ignore lists? Or have a switch for that?
It doesnt have to be a simple binary supposition … but insofar as it is then this mutually integrated configuration is more clunky than seperation.

(PS the way it is now … currently works as you fear … its just only one direction … pamac is affected by pacman conf … but not the other way around … is that expected?)

1 Like

I kindly 100% disagree. To me the way it works now is perfectly OK as Pamac is a frontend with added functionalities to Pacman.

What do you mean?

Well … This thread is all about pamac reading pacmans conf.
All while theres no hook or script or anything that makes pacman read pamac configuration.

But why would Pacman need to do that? What information should it get from Pamac?