RE: About Manjaro and AUR

[majik]

this is regarding the post, [Need-To-Know] About Manjaro and AUR

one of the major attractions to Arch/Arch-based OSs is the AUR and Manjaro’s stance on the AUR puts an unwelcome damper on that

given the nature of Manjaro (holding back updates until they’re tested), and not being a super-geek myself, i don’t know if there’s a potential solution that would make the AUR less problematic, but what i do know is that the AUR is a necessity for many people - for example, the kernel doesn’t have a printer driver for the very popular Brother HL-L2300D laser, so i need the AUR for my printer, among other things

i’m wondering if it’s possible for pamac (AUR enabled) to simply warn the user when an AUR package wants to replace a stable system file, thus giving them pause and, potentially, avoid a “bricked” system

that seems to me - a non developer, mind you - to be the easiest way to manage potential issues with the AUR

another potential solution, albeit much more involved, might be to have pamac “flat-pack” AUR packages which conflict with system files, meaning that pamac would install an essentially portable version of the program rather than allowing an AUR package to overwrite stable system files (this of course is if there isn’t a flatpak package available)

[cscs]

@majik

Manjaro’s stance on the AUR puts an unwelcome damper on that

Manjaro doesnt have a stance.
The AUR is not officially by supported by Arch - which it is aimed at - why would Manjaro support it any more than they do?

As an arch-derivative it will still likely function in the majority of cases … but much less so on the branches further away from Arch. That is the Stable and, to a lesser degree, Testing branches. Those on Unstable branch will have almost no more troubles than if one were on Arch proper.

The Arch User repository is user-generated content and a third party source.

Interacting with it in any way is the responsibility of the user.

@majik

i don’t know if there’s a potential solution that would make the AUR less problematic

Use a different branch. That is the only option.

@majik

the kernel doesn’t have a printer driver for the very popular Brother HL-L2300D laser, so i need the AUR for my printer

Are you sure about that?
Even if you need to get the driver and it needs to come from a foreign source … the AUR isnt a requirement. To install the printer driver easily using a tool. (Linux) | Brother

Besides which most of the concerns, such as those outlined above, would not be applicable to some crusty printer driver that hasnt changed since 2016 - which is the case for your Brother HL-L2300D. I dont see any reason why a Manjaro-Stable user couldnt use the aur package, assuming they can/should use the AUR at all.

@majik

i’m wondering if it’s possible for pamac (AUR enabled) to simply warn the user when an AUR package wants to replace a stable system file

This on the other hand would be a welcome addition.
pamac should not automatically replace core packages with AUR ones, at least not without prompting the user. Yet it does. This problem is not just for when packages are ‘demoted’ or similar - there are packages in the AUR with the same name as those in the manjaro repositories … so … they can get swapped when using pamac.

Anything related to making pamac less problematic is welcome, and there are more than a few glaring possibilities.

Until such a time as those changes and more are made I cannot in good conscience recommend anyone use pamac at all, but all the more so if the AUR were to be enabled.

( Aside from AUR package swapping there are various other concerns about user prompting, the ‘quirky’ workaround for not DDoSing the AUR anymore with a cache of it that doesnt work right, the issues with constantly broken permissions of directories, and the list goes on. )

@majik

another potential solution, albeit much more involved, might be to have pamac “flat-pack” AUR packages which conflict with system files, meaning that pamac would install an essentially portable version of the program rather than allowing an AUR package to overwrite stable system files (this of course is if there isn’t a flatpak package available)

This likely wont happen, and I’m not sure I agree with the perspective.
PKGBUILDs could be modified, and I wouldnt be surprised if some AUR-helper had an option for ‘output’ or similar, to set the prefix … and some extra scripting could be done to create links etc … but its all just a bit pointless.

[Ben]

@majik

Manjaro’s stance on the AUR puts an unwelcome damper on that

Sorry, can you explain any difference between Manjaro’s official stance to an Arch based USER repository and any other distribution - nobody supports USER repositories.

Similarly, if I posted a link here to a self-hosted repository for you to install something - it’s entirely up to you whether you install it or not. It is not in the Official Repositories.

Please read, digest, and understand again the word USER.

That’s someone like YOU or ME who decides to upload something - it has nothing to do with Arch or Manjaro whatsoever and whilst the AUR is a great source of repositories and pkgbuild, it is not managed by any distribution and it’s quality can vary quite wildly.

Manjaro doesn’t hold back updates on Unstable branch. On Testing they come fairly soon after, though yes, on Stable they are sometimes delayed fairly significantly.

This means that if you’re on Stable branch, the AUR for Klassy will be updated before your desktop is updated - and if you are on anything other than Unstable, I would suggest you not manage your AUR packages using Pamac.

There is no way Manjaro is going to open a can of worms and manage issues with the AUR - they manage the core system. The rest is up to us…

Having said that, I used Plasma for 8 years now - and AUR has never caused anything more than very minor issues… Choose your poison - choose your favourite AUR tool. I like yay, paru is good, and there are plenty of others depending on what features/configurations you find work well for you.

i.e. This update (to 6.3) my Klassy decorations disappeared, and Easystroke didn’t start/wouldn’t run.

Rebuilding them fixed the issue.

TL;DR

Unless you encounter a serious issue with AUR, My Experience tells me that it’s mostly hogwash and it’s not likely to do you much damage.

However, Manjaro is installed on Millions of machines - so if my statement is 0.1% incorrect, it’s too large an error for Manjaro to agree is ‘safe’.

Snapshots

Get them sorted. Instant headache pill…

Backups

Again, regular snapshots of your data…

Job’s a good 'un. I haven’t used or needed a snapshot or backup for a couple of years now - it’s just wasted disk space UNTIL you need it.

[Ben]

@majik

wasn’t talking about testing/unstable, was i

you can stick your snarky attitude

The only ‘official’ Manjaro policy I’m aware of is to tell users to avoid AUR unless they’re using unstable… and the only valid response I’m aware of to the comment about Manjaro’s delays vs AUR is ‘unstable’.

Many people assume that AUR is supported by Arch and not Manjaro and this was what I read from your comment specifying ‘Manjaro’s stance’, and this also implies that they didn’t take in the meaning of ‘Arch User Repository’.

It is not rare, many people view AUR as an official Arch resource.

@cscs

Use a different branch. That is the only option.

There you go.

Personally, I disabled AUR checks/updates in pamac’s GUI and drive carefully in Konsole - though I hadn’t realised before this thread that pamac can replace core packages without prompting - so this is a valid concern - it’s something I haven’t encountered.

Again, with the potential dangers (which I haven’t yet encountered) I always have snapshots and backups at the ready - and this, I believe, is the best solution (for me).

[majik]

@Ben

The only ‘official’ Manjaro policy I’m aware of is to tell users to avoid AUR unless they’re using unstable

that’s precisely what i was referring to - the AUR is more dangerous if running Manjaro (stable) and a potential solution i offered was to have pamac, at the very least, warn users when a system file will be replaced by an AUR package

i don’t think any other AUR helpers need be addressed, but since pamac ships with Manjaro, it ought to try to not bust the system

@Ben

It is not rare, many people view AUR as an official Arch resource.

it was always very clear to me it wasn’t - i should’ve explained this better

@Ben

Personally, I disabled AUR checks/updates in pamac’s …

that’s the problem - pamac ships with Manjaro and has AUR support, yet there’s no immediate warning to users to switch to testing/unstable if enabling the AUR

pamac could warn users in the event a stable system file is replaced which, to me, seems like a trivial task

the AUR is not optional for many users - it is a necessity and thus pamac, which has AUR support, ought to deal with it in a more comprehensive and logical manner IMO

[linux-aarhus]

@cscs

As for the ‘broken permissions’ issue - with the change recently made pamac moved away from using it’s own set of metadata - this should be gone.

Yes it has been annoying - but this doesn’t make pamac any less useful than other AUR helpers.

As for replacing system files - that is a no-go - but it is unavoidable - if/when - a package exist in AUR with identical name; even so the user may have replaced it intentionally.

@majik

Manjaro’s stance on the AUR puts an unwelcome damper on that

If the stance you refer to is the unsupported nature then you are correct and this is in line with Arch Linux itself.

DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk.
– https://aur.archlinux.org/

If you follow the link Learn more…

Warning: AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.
– Arch User Repository - ArchWiki

Generally speaking - as @cscs said

The AUR is not officially by supported by Arch - which it is aimed at - why would Manjaro support it any more than they do?

If one choose to use AUR - it should be a consentious decision based on needs - not based on a toggle with a minimal - easy overlooked warning.

Enabling AUR in pamac presents issues which may not be obvious to the casual user - hence the walk down memory lane in [Need-To-Know] About Manjaro and AUR

See below → RE: About Manjaro and AUR - #11 by linux-aarhus

[cscs]

@linux-aarhus

As for replacing system files - that is a no-go - but it is unavoidable - if/when - a package exist in AUR with identical name; even so the user may have replaced it intentionally.

There is literally pamac-cli in the AUR.
That it cannot handle such possibilities is a serious detriment.

Some of what @majik proposes are reasonable improvements that could be reasonably expected of a package manager.

I focused on branches previously, but failed to highlight that

@cscs

@majik

i don’t know if there’s a potential solution that would make the AUR less problematic

Use a different branch. That is the only option.

this is the only option in relation to “making the aur less problematic on manjaro” assuming the AUR is being used perfectly.

With pamac this cannot be assumed.

So the experience can be improved by making a different choice in AUR helper.

yay is in the repositories and is a frontend for pacman with additional AUR support.

The caveat being that, like pacman, it is cli-only.

octopi is a GUI that itself can act as a frontend for pacman and/or pacman-based aur-helpers with an interface more similar to Synaptic package manager.

AUR helpers - ArchWiki

Octopi - Manjaro

[nikgnomic]

Manjaro Official stance on AUR is in the Wiki

I have been using Pamac on Manjaro XFCE to packages for about 10 years and never experienced the worst case scenarios mentioned in the Need to Know topic

Most likely problem is that an AUR fails to build (package does not pass security checks or has a missing dependency) or package does not work.
Failure to boot or black screen on reboot are more likely to be from repository package updates
(partial/interrupted updates or missing nVidia drivers)

AUR contains a lot of outdated and orphan packages and user must use their own discernment
before building

Pamac GUI shows repository or AUR source for packages and also has options in the sidebar to show repository packages or AUR packages only, so a user could see where packages are coming from before accepting responsibility for updating system
(but not unusual for some users not to notice what is presented in a GUI)

If an AUR package has an identical name to a repository package (rare) but a later version number, any AUR helper is likely to update package to AUR version. For this situation user needs to be aware of which packages might be affected, ignore AUR update and wait for the repository package to update

If a repository package is dropped from Manjaro repositories to AUR, user might want to continue using that package

Some AUR packages are available as an appimage

@cscs

There is literally pamac-cli in the AUR

There is also yay in AUR

[Pille]

I have the need to use a few packages from AUR on my stable installation. Reason: I don’t want to fiddle around with configs, compilers etc. Just laziness.

But i am reading carefully the package information before installing it. That’s what always required together with the general rule of thumb to not install things without knowing what they are doing. If i am unsure what’s going on, i am not installing it.

On my wifes devices there is no aur package, because i want to keep her device hassle-free.

[linux-aarhus]

This one needs to be addressed separately as it will clear up a common misconception

@majik

i’m wondering if it’s possible for pamac (AUR enabled) to simply warn the user when an AUR package wants to replace a stable system file, thus giving them pause and, potentially, avoid a “bricked” system

AUR buildscripts THE PKGBUILD provides files not available in the official repo (Arch) and the guidelines are very strict.

→ See AUR submission guidelines - ArchWiki

The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances.

These guidelines states THE PKGBUILD must not provide files provided in/from the official repo.

This means THE PKGBUILD will never provide any file that replaces system files; this is valid for all branches of Manjaro and it is valid for Arch Linux.

Therefore THE PKGBUILD contains a depends=() array, stating which packages is required for the result to be usable.

If a package with the same name exist e.g. yay or pamac-cli - those packages will build from source and thus they will not (should not) interfere with normal operation of apps provided in the Manjaro repo.

Packages that use prebuilt deliverables, when the sources are available, must use the -bin suffix. An exception to this is with Java. The AUR should not contain the binary tarball created by makepkg, nor should it contain the filelist.

If THE PKGBUILD provides precompiled binaries - the rules requires a -bin suffix to the package name e.g. paru-bin vs. paru where the latter is being compiled locally.

Because the source for e.g. google-chrome is not available the -bin suffix is not required.

[cscs]

@nikgnomic

@cscs

There is literally pamac-cli in the AUR

There is also yay in AUR

Yeah but it doesnt mean the same thing.

Pamac has problems distinguishing between the two and does not properly prompt the user.

Yay has neither issue - even if it did somehow offer to replace itself with the AUR version it would present an actionable dialog for the user.

“False equivalence” in a certain parlance.

@linux-aarhus

The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances.

These guidelines states THE PKGBUILD must not provide files provided in/from the official repo.

This means THE PKGBUILD will never provide any file that replaces system files; this is valid for all branches of Manjaro and it is valid for Arch Linux.

No, its not valid in the same way.
Its actually a perfect example of the differences of using Manjaro or Arch with the AUR.
Arch can enforce this on both ends.
Manjaro cannot. It could choose to either work with AUR maintainers and/or strive not to have same-name packages in its own repositories. But it does neither - the opposite in fact.
Manjaro adds yay to its repos whilst it exist in the AUR.
While on Arch yay being in the AUR is a non-issue because … there is no yay in their repos.

This problem is compounded in the case of something like pamac-cli because of its own inability to properly handle these situations nor even present the user with notification or choice.

[linux-aarhus]

@cscs - I remember the single incident you may be referring to.

Many moons ago one uploaded a PKGBUILD with same name as a core package (pacman-mirrors) using date as version. That created some problems for those building AUR packages as an integral part of their system maintenance.

I don’t recall how it was worked around but such issue is hard to avoid.

One method to avoid would be to maintain a list of packages which exist with the same name in AUR - who should do that? And when?

Another method would be to check every package name in an update for duplicate entry in AUR but this would introduce an unacceptable overhead to pamac.

You One can blame Manjaro as distribution as much as you one want

• but the fact remains
• sysadmin is responsible for the local system

The majority is

• one little piggy want a different OS
• one little piggy go to market
• one little piggy find a free system
• one little piggy enables AUR
• one little piggy breaks the system
• one little piggy blame the system for allowing to be broken

Then the little piggy see’s hyprland and goes candy crazy and want it all - but don’t know it is maze you cannot exit.

[cscs]

@linux-aarhus

You can blame Manjaro as distribution as much as you want

Point to where I did that?

If theres no room for constructive criticism then all is certainly lost.

What I was doing was mostly just clarifying the situation.

Manjaro presents particular problems with the AUR, as already outlined with things like packages and branches.

Pamac is its own complication because of its poor handling of the AUR.

“Fundamentals” like properly prompting the user are not ridiculous asks.

And they should be taken seriously if pamac is ever to be taken seriously.

( To say nothing of other concerns like being able to handle split-packages … which it cannot. )

[linux-aarhus]

@cscs

Point to where I did that?

My apologies - I must have misunderstood something - I have rephrased to avoid misunderstanding.

In any case - we can use the phrase you as a generic denomination…

[nikgnomic]

@cscs

Pamac has problems distinguishing between the two and does not properly prompt the user.

Pamac GUI shows source repository or AUR for individual packages:

and has a sidebar to show AUR packages only:

Pamac CLI shows source repository or AUR in package list of updates before user is requested to allow updates

@nikgnomic

@linub

wouldn’t this cause issues for users that have AUR+updates enabled?

Yes, it can cause similar issues for users on stable branch when update announcements are delayed and AUR has a later version available

That is why experienced users suggest updating Repository packages before rebuilding AUR packages

[andreas85]

@majik

you can stick your snarky attitude

I would like to point out that we like to discuss controversial technical topics.
However, it is important to show respect to one another despite different opinions. Please pay attention to the tone of your contributions!

[majik]

@linux-aarhus

As for replacing system files - that is a no-go - but it is unavoidable - if/when - a package exist in AUR with identical name; even so the user may have replaced it intentionally.

right, but this is where a warning is useful and pamac could/should provide that IMO

@linux-aarhus

If the stance you refer to is the unsupported nature [of the AUR] then you are correct and this is in line with Arch Linux itself.

right, but it’s obviously different with Manjaro stable

again, Manjaro is aimed as less technical users and as such it ships with a graphical package manager that supports the AUR - is there any reason to not make using the AUR safer (warn when conflicts with system files, or whatever, are imminent)?

@linux-aarhus

This means THE PKGBUILD will never provide any file that replaces system files; this is valid for all branches of Manjaro and it is valid for Arch Linux.

ignoring the possibility that a bad/malicious AUR package could be a worm that starts WW3, isn’t one of the concerns conflicts with system files? for ex., a 10 yr. old AUR pkg attempts to replace a system file that wasn’t a system file 10 years ago

@nikgnomic

Pamac GUI shows source repository/AUR individual packages and has a sidebar to show AUR packages only

so in addition to my original suggestion, perhaps pamac ought to display a big fat warning when that switch is toggled

@andreas85

Please pay attention to the tone of your contributions!

off topic, but it wasn’t me that was being unnecessarily argumentative

i’m a bit surprised at the notable dislike of pamac by senior people here - i didn’t realize that pamac is this problematic, and this begs the question, why aren’t such problems getting fixed? are the dev(s) resistant?

aside from the issue i raised, there’s no shortage of bugs

anyway, pamac ships with Manjaro and thus i think users would appreciate if it handled the AUR better

i’ve never had a problem; i check repo links and build files, but the average Joe may not and though it’s their responsibility to do so (i hear ya), it seems pamac could be doing a better job handling the AUR and i suspect that it wouldn’t be difficult or overly time consuming to warn when an AUR package is going to collide with something it shouldn’t

• warn of package conflicts
• warn user when enabling the AUR (perhaps an agreement style warning with an “i accept the risk” button)
• although pamac marks packages from the AUR (text), perhaps the background color for those boxes ought to differ from non AUR packages, at least when the “all” category is selected -AND/OR- perhaps AUR packages should be listed below, and separated from (header), stable packages instead of being mixed together

[linux-aarhus]

@majik

@linux-aarhus

even so the user may have replaced it intentionally.

right, but this is where a warning is useful and pamac could/should provide that IMO

If the user is activating AUR then further messages is irrelevant as the user is then familiar with the process or intend to familiarize.

@majik

@linux-aarhus

If the stance you refer to is the unsupported nature [of the AUR] then you are correct and this is in line with Arch Linux itself.

right, but it’s obviously different with Manjaro stable

Slightly - yes - e.g. yay in repo is one version older than the version in AUR - technically it could happen but such package is usually fasttracked to all branches.

@Yochanan is a very competent and capable maintainer. to him for being just that.

@majik

Manjaro is aimed as less technical users and as such it ships with a graphical package manager that supports the AUR - is there any reason to not make using the AUR safer?

In my opinion - It cannot be safer than it already is.

I have been - internally, been suggesting that we remove AUR support from stable branch; I didn’t gain much traction but with the work on the immutable Summit edition - the focus will be on flatpak support only - so I have hope that, at some point, AUR functionlity will be moved into a separate plugin package - much like it is now for flatpak and snap.

 $ pamac search pamac --no-aur
libpamac-snap-plugin  11.7.2-3                                                                  extra
    Snap plugin for Pamac
libpamac-flatpak-plugin  11.7.2-3                                                               extra
    Flatpak plugin for Pamac
libpamac-debug  11.7.2-3                                                                        extra
    Detached debugging symbols for libpamac
libpamac  11.7.2-3 [Installed]                                                                  extra
    Library for Pamac package manager based on libalpm
pamac-tray-icon-plasma  0.1.3-3                                                                 extra
    Pamac tray icon for Plasma users
pamac-gtk3-debug  10.7.0-1                                                                      extra
    Detached debugging symbols for pamac-gtk3
pamac-gtk  11.7.2-2                                                                             extra
    A Package Manager based on libalpm with AUR and Appstream support (GTK4)
pamac-gnome-integration  11.7.2-2                                                               extra
    Pamac GNOME integration
pamac-debug  11.7.2-2                                                                           extra
    Detached debugging symbols for pamac
pamac-cli-debug  11.7.3-1                                                                       extra
    Detached debugging symbols for pamac-cli
pamac-gtk3  10.7.0-1 [Installed]                                                                extra
    A Package Manager based on libalpm with AUR and Appstream support (GTK3)
pamac-cli  11.7.3-1 [Installed]                                                                 extra
    A CLI Package Manager based on libalpm with AUR support

You are of course free to voice your idea at GitHub - manjaro/pamac: Graphical Package Manager for Manjaro Linux with Alpm, AUR, Appstream, Flatpak and Snap support - be sure to search for similiar idea and upvote that instead of creating a new.

[nikgnomic]

@andreas85

Please pay attention to the tone of your contributions!

OP is not posting about Controversial subject (Sports,Politics or Religion)

How to Disagree
Responding to Tone.

The next level up we start to see responses to the writing, rather than the writer. The lowest form of these is to disagree with the author’s tone

Though better than attacking the author, this is still a weak form of disagreement. It matters much more whether the author is wrong or right than what his tone is. Especially since tone is so hard to judge. Someone who has a chip on their shoulder about some topic might be offended by a tone that to other readers seemed neutral.

@majik

i’m a bit surprised at the notable dislike of pamac by senior people here

Pamac is made by Manjaro Team and hated by some forum users who do not respect the ethos that this is “your system under your control”

@majik

why aren’t such problems getting fixed?

Maybe because users are often suggested not to deal with pamac issues but to use another package manager or AUR helper

@majik

it wouldn’t be difficult or overly time consuming to warn when an AUR package is going to collide with something it shouldn’t

Manjaro is not responsible for users that do not read and understand the package updates offered by pamac

[brucew]

If I may interject here, I’m a big fan of pamac. It is far and away the nicest package manager GUI I’ve ever used. I’m certain there is room for improvement, just as there is in any human endeavor. But that doesn’t change my opinion.

I’ve recently begun exploring upstream. Yes, I used the archinstall script.

With the basics done and Plasma running, the very next thing I did was (using yay) install pamac. Imagine my surprise when Arch won’t let you use the AUR in pacmac. Bearing in mind that I’m an ordinary human, and I haven’t yet begun researching, no amount to clicking in Preferences or editing /etc/pamac.conf seems to make any difference.

If Arch has made this choice, there’s probably a very good reason above and beyond that it’s not “The Arch Way”. I’m not at the level where I could speculate why. I merely report this.

I’ll add that I use several things from the AUR on my Manjaro installations. All of them installed with pamac. Dysgraphia and dyslexia combine to make me a poor typist who can’t see his typoze, thus I lean hard into GUIs.

It wasn’t obvious to me at first, but eventually I figured out how to make the best decision when there are several AUR packages of the same thing. The worst thing that has happened thus far is something that won’t build then aborts. I clean up and move on.

As with the OP, I also use an older color laser printer (a Canon) that does not have out-of-the-box support in Manjaro. It’s simply because I already own it and I no longer print often enough to justify the purchase of a new one. I have a hard time justifying the purchase of a dozen pencils, simply because it’s more than I’ll use in the rest of my lifetime.

After researching over in Arch (the forum and the wiki) I was able to get it running perfectly, after several many typoze. While it would have been nice to have it work OOB, or to be a point and click install after the fact, I accept the limitations the team has to work within. Foremost of which are time, money and personnel who have enough of the other two.