Proposed Pamac AUR Update Delay

Convenience? I know how to build programs. I did so manually for the missing things when I was on my former distro, and you can do so on any Linux or BSD system. However, it isn’t really convenient. You have to figure out all the dependencies, get the sources, most distros (artifically) split packages in the “normal” part installed and the “dev” part (these are the include files well the public ones if private ones are used for the build you may search for the whole source code package) - and so on.

The AUR is convenient since this work is already shared - you get PKGBUILD scripts. But you still need to build the package manually. So next convenience is to automate this and yes automating means to skip over things - that exactly is the purpose of an AUR helper. There is even a further step regarding convenience - make a GUI for it. But one should not be misled to conclude because anyone is able to click a button such a GUI tool would be made for everyone. Nor should one conclude that the folks who know how to do all of this (building manually etc.) wouldn’t deserve convenience because they wouldn’t need the button to click on.

Anyway, the real question is whether adding a delay option would be any improvement. Now I have a hard time to see the improvement because or although I know all this? At least for myself I can clearly state the option would be no improvement for me.

2 Likes

Delaying updates for all AUR packages would delay security patches that users should be made aware of as soon as possible. Security updates for repository packages are usually fast-tracked to all branches without delay for optimal security

Manjaro delays release of packages to stable branch to avoid users having to deal with a partial update (only unstable branch has to deal with sort of thing). Delay also allows users on unstable and testing branches to identify any issues and provide solutions for stable branch updates

Because it is “your system under your control” and pamac respects your freedom of choice

Pamac GUI has 4 tabs to review AUR package documentation before building – Details, Dependencies, Files and Build Files. Documentation can also be reviewed online – aur.archlinux.org

If a user selects packages to build and clicks Apply in the main window they are presented with a popup window with 3 options – Edit Build files, Apply or Cancel
If a user then clicks on Apply in the popup window, they are presented with another popup window to input password and Authorise the build, or Cancel
Clicking on Authorise is the “point of no return” and pamac should not be interrupted whilst building packages

Pamac CLI has 3 options for building AUR packages

Edit build files : [e] 
Apply transaction ? [e/y/N]

The default option here is N to cancel the transaction
selecting y will request authentication password to build packages

4 Likes

I wasn’t going to respond but Ben decided to chime in at another forum so it bears repeating and expanding.

What’s interesting has been the non stop debate of supported vs unsupported and the user blaming. For a distro which’s primary description is “a focus on user-friendliness, accessibility, and improved software testing and stability compared to its upstream sources” community staff sure don’t seem to practice any of that in this thread or relation to AUR. I respect the dev here who while I disagree with in some aspects do respect they proposed an alternative solution.

I used to wonder why Manjaro consistently decreased in adoption rate while Linux desktop adoption has never been higher, and while I used to think it was the users leaving for more advanced or preferring more control or more frequent updates, I feel now instead it’s the staff who left the users.

Just for the record, I’m not a developer, even though I have already made a few modest contributions. :wink:

Please don’t buy into PR speak — not even Manjaro’s. As I have explained already, the description on the website was aimed at indiscriminately attracting as many users as possible, and thus, as many customers as possible for the Manjaro GmbH, from which we are (organizationally) going to split off.

Things are a lot more complicated than that, but that subject is off-topic for this thread, so I’m not going to get into that here.

As for user-blaming, as we said earlier already, we expect our users to assume responsibility, but just because we expect that doesn’t mean every user will agree. If that were the case, we’d be living in a world without war and without crime.

People are people, wherever you go.
– Depeche Mode

1 Like