v86d was dropped from Arch repos and moved to AUR, but it can’t be removed, because mhwd depends on it.
1 Like
mhwd should no longer depend on v86d.
The dependency was removed at the same time as v86d was dropped.
1 Like
So the order of the updates is crucial.
The problem is, that Manjaro has no influence on v86d dropping to AUR and it already happened, while mhwd update that drops v86d dependency came later. So most users will have to update it with AUR package and then remove v86d.
No, v86d was an AUR package that manjaro was building and putting in the repos itself.
Manjaro was maintaining it. Manjaro dropped it. When manjaro removed it from the dependencies of the one package requiring it.
Ah, got it. So this means, Manjaro dropped v86d from repos too soon. It should have waited for people to update mhwd and then remove v86d, which would show in orphaned packages. Now it forces to update first with AUR package. This isn’t a problem, but not an elegant solution, considering fact that Manjaro package requires AUR package when AUR is not officially supported ;).
For stable branch, dropping v86d should be delayed a bit, maybe a week or two.
The update should itself not require v86d because the new version of mhwd … does not require it.
I dont know how you would possibly get a new version of mhwd, and have v86d missing from the repos all at the same time … but somehow mhwd still relies on v86d. It doesnt really make sense.
Please show your output.
Too late. I already updated with v86d as AUR package and then removed v86d.
If it happened in my case, I bet there will be others with similar “issue”.
When I checked v86d dependencies in pamac, it showed that mhwd depends on it, so the mhwd in the system still required it.
This should be chained, so the mhwd updates first, but since it v86d is AUR package and treated separately, pacman asks to build it BEFORE applying the update, so still checking dependency with EXISTING mhwd.
So basically, AUR package has sort of priority. To avoid that v86d should still be in Manjaro repos and mhwd update should be schedudeld before v86d.
Im kinda doubting it as no one else has mentioned any problems.
Then again … maybe you use pamac?
And maybe pamac just was updating the existing AUR package.
You know … upgrades dont just remove things when they are no longer required.
Ah, so you do.
This is just another example of the problems of updating AUR+repos at the same time in general, and pamac itself in particular. Double so if pamacs default mode of operation is to … build AUR packages first.
There was never any issue with the dependencies.
Usually, with big updates, I just do it from terminal and then update AUR packages from pamac. However, in this case, because there were no kernel packages, I did the update in pamac, like most of the average users will, so this “issue” will happen for others as well.
Like I said, you dropped v86d too soon, because pamac saw it as AUR package when checking for updates and forced it as a first, against current dependencies.
You did a combined repo+AUR update in pamac.
For this and many other reasons I dont suggest using pamac at all, but for those that do I would suggest disabling the AUR.
There is nothing wrong with how v86d was removed and simply numerous things wrong with pamac.
Like this. This shouldnt be how a 1st-class package manager acts.
That is if it really was like that.
We cant know, as no output was ever provided.
But I still think it would be odd for mhwd to have a perceived v86d dep before the upgrade, but not one after. It just doesnt make sense from a repository standpoint. So maybe there was something wrong with your mirror or sync. Or maybe its just more pamac problems.
Why would I fiddle with that? It’s convenient for pamac to handle AUR packages, even if in some cases it has issues with building some files, while yay works fine.
AUR packages are crucial part of Arch ecosystem and one of many reasons why Manjaro is so awesome. Sure, officially Manjaro won’t say it supports them, but for most users (if not all), using Arch system without AUR is just stupid. And if there is recommended Manjaro graphical tool to update the system, it is logical that the first step is enabling AUR in it.
Suggesting to turn AUR support off during updates and then turning it on, makes no sense. Either you have a convenient GUI app or you don’t. If pamac is so problematic, why is it installed with Manjaro by default and in Manjaro repos? I thought this was the point, to give average users a convenient GUI tool, so any updates that are dependent on Manjaro decisions, should think through the consequences as if the majority of users used pamac.
No, I think there is no error here. Pamac must check AUR packages first against repo ones, to find out if there are no repo packages to install there, and that does happen.
Good question.
My answer would be something having to do with shiny GUI and being different.
But this is not the space for discussing the drawbacks of pamac … again.
I actually didnt suggest that. I suggested turning off the AUR in pamac in general.
The AUR is unsupported, even in pamac, no matter how many convenience points you ascribe to it. Pamac has problems, But it has them in triplet if you add the AUR.
Pamac has never worked like that.
Its a recurring problem that it will replace repo packages with AUR ones if it feels like it.
Look … I would have loved to actually observe whatever problem it was that you were having. But we cant do that anymore.
I still think it rings odd to me that v86d would be required by the new mhwd but then not required after the upgrade is finished. It does not make sense.
Are you sure v86d was being pulled as a dependency and not simply being upgraded?
I suppose it does not matter any longer.
Note: Content moved from Unstable Updates to the Member Hub for further discussion and clarification.
I held up the 
STOP sign as the premise of the discussion was based on a completely false assumption. Clearing that up was the goal.
Remember everything on the internet is indexed; sometimes within minutes–especially a high-traffic website like this forum.
You saw my reply in the Unstable Updates thread, right?
It appears @cscs was able to answer questions and clear up any confusion. Thankee sai! 
Either way, I understand it can be confusing when a repo package is dropped and an AUR helper offers to update it. However, using the AUR is a user’s own responsibility. It’s up to them to manage and maintain those packages.
Note that this change is only in the Manjaro unstable branch thus far.
All systems go. Feel free to speak freely.1
Sorry about the interruption. Think of me as a plumber who saw a leaky pipe. 
1That means you may also smack me upside the head if you think I did something wrong. S’okay, s’alright
A package is dropped to AUR, it is still installed on user’s system. And if it happens, like in this case, that version in AUR is higher, so in need of update, in the same time when mhwd was still not updated and pamac sees current, not future dependencies.
I assume, that if both packages were in repo, dependencies are cleanly resolved by pacman, but since one package is no longer in repos, pamac checks both, AUR and repo updates.
Before the update I couldn’t remove v86d, because current mhwd was still depending on it.
It looks like the v86d’s update in AUR caused this unfortunate mix. Otherwise, I wouldn’t even see it. I would update as it is and v86d would show up as orphaned and AUR package which happens from time to time with various other packages.
Please, correct me if I got the mechanisms wrong, but so far it makes perfect sense for me and the combination of dropping the package before the update happened on my system and the update in AUR available created this combination.
Again, this isn’t an issue, but it’s likely to happen for stable users as well, unless v86d in repo will be updated to AUR version and removed slightly after the mhwd update release. Unless, you don’t see any problem in this and expect users to do what I did, to do the update and then removed orphaned v86d.
@michaldybczak First of all, I just wanted to let you know I appreciate your feedback as a user of the Manjaro unstable branch.
To clarify, when one says a package is “dropped to the AUR”, that means it was previously in the Arch repos and did not exist in the AUR until the Arch PM (Package Maintainer) removed it from the Arch repos and created the AUR package. When that is done, it is disowned by the Arch PM so that anyone can pick it up and maintain it if they wish.
In the case of v86d, as I mentioned it has been in the AUR the whole time. I dropped it from the Manjaro repos. Nothing to do with Arch at all.
Either way, the v86d package is now an orphaned package regardless if it’s in the AUR or not. It should be managed just like any other.
One must keep in mind most Arch and Manjaro users do not use the AUR at all. If they do, they either manually enabled the option in Add/Remove Software (Pamac) or manually installed another AUR helper like Yay.
Disclaimer: Keep in mind the AUR is neither officially supported by Arch nor Manjaro.
Pamac default mode of operation is to update Repository packages only
To update Repository + AUR packages at the same time there is CLI option
--aur, -a : also upgrade packages installed from AUR
Pamac GUI has 2 options that are not enabled by default
Enable AUR support and Check for updates
If Repository and AUR packages are updated at the same time, pamac is likely to offer to install an AUR package to replace a Repository package that is outdated or no longer available
(similar to other AUR helpers)
Pamac GUI users should check the package list before agreeing to update and un-check any AUR packages
1 Like
That conversation was moved to another thread.
But if it needs clarifying then I will reform it as
“If pamacs default mode of operation when the AUR is enabled is to build AUR packages first…”
It would be an odd thing. I had thought it did it in a jumbled fashion, as has been observed previously. But I was also responding directly to another users anecdote of pamac upgrading AUR packages first. Which would be the opposite of the preferred order, and the opposite of other tools that support both such as yay or paru, which would all build AUR packages after the repository packages are synced/upgraded.
@nikgnomic I just moved the relevant replies to the proper thread.
If AUR is enabled pamac is not operating in default mode and user is expected to be fully aware of the risks and responsibilities
Pamac GUI users should check the package list before agreeing to update and un-check any AUR packages