21

Great information, thankyou for this :+1: :smiley:

1 Like

If you have basic common sense and read the pkgbuild, you can’t be suprised easily. Aur is completly fine. paru is the best for binary packages, yay for -git packages, pikaur when you need to edit the pkgbuild.

Check it out AUR (en) - bottles

24

@CacheMeIfYouCan - Your script is fantastic, an absolute masterpiece of bash scripting! Well done and many thanks for sharing it :+1:

1 Like

25

In what way?

How?
Cachy generally suggests avoiding them because they are not optimized.
And I happen to dislike them.

But I just wonder where this idea comes from.

Same for this.. why is paru better at binaries and yay at git packages?

The only thing I can think of this referring to was a lot longer than 1 month ago.
And was not really new and never really meant anything for the ‘security’ of using the AUR - its safety has always been its transparency. The user must be responsible for reviewing the publicly produced PKGBUILDs. If they cannot then they should not use the AUR.

I guess it was DDoS’d for a moment but that only resulted in it being difficult to load at times.

1 Like

26

After using linux since 2001, and now seeing the influx of people to Cachy, I think you may be onto something here :slight_smile:

Rolling release distros usually ship much newer dependencies than what Flatpak apps except, and this was flatpaks are prone to break dbus. i even heard about them breaking systemd, bricking the system. I use paru for binary packages because yay always cleanly compiles source-based packages, while paru caches binary releases aggressively, which is why it can be faster than yay sometimes.

Malicious packages occur like once in a year. This is useless but not malicious

“Completely fine” is doing a lot of work there - YES if you have enough time and expertise to read every PKGBUILD and understand every detail you’re reading - but then you’re just reducing the risk, and that’s a big “if”.

I’ve seen deceptively complex pkgbuilds - expecting average users, or even advanced users, to always spot a problem (especially if it’s hidden in a helper script…) well that’s just too bold a claim.

Sure, you can GET AWAY with using it for a long time, there’s no guarantee… which is why backups/snapshots are valuable.

Your ‘once a year’ claim also ignores that many will actually go unnoticed unless someone really digs into them.

But you also claim odd differences in Paru and Yay and Pikaur, I don’t find Pikaur unique there…

There’s also no real difference between paru and yay in terms of binaries vs GIT builds… it’s more about personal workflow.

Again - I use AUR a lot.

I treat it as ‘USE WITH CAUTION, Verify what you can, always have backups/snapshots ready’.

31

How could a containerized flatpak break systemd or a brick a system?

Flatpaks should not normally have any dependencies - they are containerized - thats kind of the whole point of something like flatpak.

Granted sometimes the packagers makes certain assumptions - such as that the user is on Ubuntu or otherwise. Though this is more common with SNAP and is not technically inherent to any of the container technologies.

And there is still very little danger. The worst a flatpak should be able to do, from some sort of ‘dependency’ standpoint is not be able to run itself.

So what was the end of this all?
You stopped using flatpak and it works better?

Great.

We might again re-assert that flatpaks are third-party containerized software, not supported or provided by Cachy, and should not really be related to ‘system updates’ (ex: pacman) in almost any way.

They could be rightly understood to be more foreign than the AUR. And I for one find them less secure than PKGBUILDs if only because you cannot inspect them.

3 Likes

I was going to argue that the reverse is true if you’re not very good at reading pkgbuilds - but that wouldn’t work, because if it’s not something brand new, then there’s an excellent chance that it is also being read by others… the major benefit being that it’s open.

1 Like

This occurred in the Manjaro forum last month, if you make the browser narrower until the layout shifts then they come back.

However, it’s all good for me in Firefox here right now.

34

Flatpak apps still depend on the host (kernel, drivers, libraries, etc.), so updates to those can break things (b/c new versions can break backward compatibility, require new configuration, regressions/bugs etc.) even when Flatpak itself didn’t change. On a fast moving RR system, that’s kinda expected and it’s only a matter of time before it happens.

Btw this isn’t specific to Flatpak. The more complex your setup, the more maintenance it needs, especially on a fast moving/bleeding edge RR distro. Simpler systems are easier to maintain and keep stable.

This is one if not the only or main reason why many people prefer snapshot based LTS systems, especially for work (OC these come with their own issues and trade-offs.)

35

The user claimed some flatpak caused the OS systemd to “brick”.

Containerized apps cant do that.

As mentioned above - they may stop being able to launch for one reason or another. But they dont change (or break) some system service manager.

At least they should not be able to.

And if there are examples then I would like to know of them.

1 Like

36

Yeah, I wasn’t replying to them. I was just trying to provide some context regarding the claim that ‘Rolling release distros with Flatpak is a very dangerous combination,’ which you reasonably questioned. To be clear, I’m not supporting that claim. I just mentioned what I think might have led to that thought process or influenced someone to reach that conclusion.

1 Like