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