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?)
I dont think it should.
I just find it interesting that some perspectives would have the opinion it should work in one direction or instance and not another. In the case of ignored packages … parts of this thread would like pamac to honor pacmans ignore list … but if pamac had its own ignore list pacman would not read or care.
So even without changing anything … the current situation is not standardized … so there is a mixture of expectations that dont follow an intelligible rule. (generally that is not normally how we would like to develop or consume software)
To maybe put it another way … this was less of an issue when pamac was more of a ‘pacman wrapper’ or ‘pacman extension’ … but now that it may be considered a ‘pacman replacement’ … well the issue lies in not being sure … it must be one or the other … not both.
Well the ideal way to solve this would be to have a systemwide ignore list somewhere on the system for each and every package frontend/manager out there to come and check when needed. Something that needs to be standardized amongst each and every package manager/frontend developer for each and every program handling packages in any form to come and check when needed and possible also write. That way the user could install any package manager he/she pleases and expect them to be able to have the needed communication so that when he/she would like a special package to be ignored then every other program that handles packages would pick up and just ignore the package right away. That would be ideal but of cause that would mean that every developer out there would need to agree on a way to do this so that we don’t end up with 10000000 different standards like it is today. If someone come up with a format for this and a standard place on the file system to expect this file then it would be great news for the user and for other developers not needing to write and read other programs files because I agree with @linux-aarhus that this is bad. It’s just that this is the only means of communication right now because such standard doen’t exist right now.
And even then there is problems down the way needed to be resolved first as some packages even don’t have the same name across distros, even though they contain the exact same files, so that’s another hurdle to tackle for developers. Now that Pamac moves away from pacman, what if the user still wants pacman to be installed for some reasons. How is Pamac supposed to communicate with pacman (if the user installs it) to avoid duplicate installation of packages from AUR/snap/flatpak or whatever there is? Until someone comes up with a centralized way to handle that kind of situations, the one we used today where pamac (which can deliver packages from most sources (alpm/AUR/snap/flatpak)) writes and reads pacman.conf (which can deliever packages from the least sources (alpm)) is the best. Not the most correct way to do things, I’ll agree to that, but the best way to do things today from a users perspetive and the most userfriendliest way to do things by today’s standards.
Something like libalpm.conf, or perhaps a list or db pointed to by such a conf file? (Assuming libalpm is a common denominator across the package managers, which it might not be …)
Somewhat related, are there other uses of ignore than the above function of freezing or fixing in place the package version?