Updating AUR programms

markus_03 · 2016-01-03 06:04:41

After installing an AUR programm by using makepkg -sri on the PKGBUILD file, is there any way to update that programm like with pacman -Syu?

Or do I have to look for new AUR releases myself and run everything again by hand?

I did not find any clear information about this on the wiki.

Scimmia · 2016-01-03 06:07:00

Pacman doesn't handle the AUR at all. You'd need to check it yourself and rebuild.

This is one of the situations where AUR helpers come in handy.

jasonwryan · 2016-01-03 06:17:30

Moving to AUR Issues...

bharani · 2016-01-03 07:19:35

You need to use AUR helpers https://wiki.archlinux.org/index.php/AUR_helpers

If you use packer then you can run

 packer -Syu --auronly

yaourt can also do this.

yaourt -Syua

mpan · 2016-01-03 08:05:06

You don't need an AUR helper. You may want to use want, but it's not required. The basic method for updating AUR packages is the same as with installing them: by hand. I appreciate helpers, I'm using yaourt myself as my primary package manager, but you must remember that all helpers are just rudimentary aids that automate the build process, which have their pitfalls and you have to be able to build package yourself and understand the process.

Helpers will not detect that the version in the VCS has changed (applies to *-bzr, *-cvs, *-git, *-hg, *-svn packages). You have to track updates yourself — for example per mailing lists, RSS and similar means. Many AUR package maintainers will bump pkgver or pkgrel on important updates, but this is neither required of them, nor there is a standard for doing this.
They can't rebuild your package because dependencies has changed. Again, you have to do this yourself by rebuilding and reinstalling the package. You can write a script that will let you automate the thing a bit, but it's outside of helpers' scope.
AUR packages are not as stable as official ones. Both in terms of runtime stability and building. Ater building a package you may realize that it's broken. Also the building itself may fail, leaving you in the middle of nowhere with half AUR packages updated, the other half not. You need to be able to crawl out of the situation yourself — a helper will not solve this.
Building packages often requires installing build-time dependencies. You have to manage them post install manually, if you don't want to keep them. And not all helpers will tell you which ones are that, just like some that do this (yaourt for example) may fail to do so in case of an error.
Updating a package is not more secure than installing it for the first time. You still have to check the package if it's safe to be installed.

markus_03 · 2016-01-03 23:27:33

Thank you for the answers.

As I understand it, the use of AUR packages comes with some sirious drawbacks.
Using it for like kernel and other software that needs to be updated reguraly would mean a lot of work and potential issues.
Thats unfortunate.

I feel like this should be explained more clearly in the introduction section in the wiki

firekage · 2016-01-04 10:23:28

markus_03 wrote:

Thank you for the answers.
As I understand it, the use of AUR packages comes with some sirious drawbacks.
Using it for like kernel and other software that needs to be updated reguraly would mean a lot of work and potential issues.
Thats unfortunate.
I feel like this should be explained more clearly in the introduction section in the wiki

I use Aur from the beggingin my way with Arch. I don't agree with that. Aur packages can be broken, something could be missed in them...but always you can check at Arch website what is wrong with it, how to fix it, what to change - for an example, after switching from I5-4670K to I7-6700K i had seriously big problems not with aur packages, but with all packages, even officjal, on Arch website and similar ones all people with Skylake had them. Glibc was giving me a massive amounts of segfaults. I compiled new glibc and was able to do it, in few tries, using ABS, that i never understood, now i now, not everything but i was able to compile glibc with fix for Skylake, for Arch, and packages for aur using Arch website, infos, know how and so on.

You wanted to update aur packages - earlier said

 yaourt -Syua

i use the same version but

 yaourt -Syu --aur

If package is broken, or if it conflicts with sometghing, just remove it, and build with Aur again. It could go ok. For an example, i use MDP that is official in Arch repo as a server. As a client i use for an example, Sonata, Gnome music player deamon...and for gnome music player deamon i have installed from aur plugins (gmpc-lyrics for an example, to be specific).

It is not that there is always a problem, and just it does not work. I use it, i don't have seriously big problems, if i have them at all.

Last edited by firekage (2016-01-04 10:26:36)

Trilby · 2016-01-04 12:57:52

markus_03 wrote:

As I understand it, the use of AUR packages comes with some sirious ~~drawbacks~~ responsibilities

Fixed that for you.

Use AUR packages. That's what they're there for. Just know what you are doing, and don't use them blindly. Don't assume an unrated and little used AUR package will work properly. Do assume that a flagged AUR package will likely break something. But for actively maintained well-rated (voted) AUR packages, you'll likely have no problems at all: there are no "drawbacks", just a responsibility to be aware of what you are installing.

mpan · 2016-01-05 08:43:53

@markus_03
You're getting bad perspective. AUR is advantage over how the software is being build without AUR.

Judging by the reaction, I assume you came to Arch from Windows¹. On Windows it's a standard that you're giving control over you system to some random folks to configure it for you [and not rarely also break half of it]. In the Linux world you are the administrator and you rule your computer. But power and freedom also comes with responsibility and, quite often, some additional price. That price is requirement to build your software yourself, keep track of versions and so on.

At some point there came an idea that if there is a distro and nearly all users are using very similar configuration, software can be built centrally and then distributed in a binary form. And a nice and convenient tool for managing such packages and their dependencies has been created. This is what official repository and pacman is, in the case of ArchLinux.

But package maintainers are not able to compile and test every software that is out there — they can only take care of a tiny fraction of the most important applications. Everything else you still have to manage yourself. Since not everything always works as expected and it's not always straightforward to build a program, and also people tend to help each another, the next idea is to create a big collection of such build tips in one place. This is what AUR is: just a bunch of descriptions provided by other users, who already managed to build given package, to users, who need a help with it. Nothing more. It's just like a forum on which you could ask on how to build software Xyz-0.1.2 and get the answer, but in a predefined, organized, machine-processible format to allow easier use in semi-automated scenarios.

The point is that you should realize that "the normal way" is actually getting all over the build process yourself, without any help. AUR is a great advantage over that, by providing you with read-to-use scripts that build the software for you. And pacman is even greater help on top of that all for managing the most common applications.

____
¹ Not something to be ashamed of. Most of us here did that.

markus_03 · 2016-01-06 16:21:19

Trilby wrote:

markus_03 wrote:
As I understand it, the use of AUR packages comes with some sirious ~~drawbacks~~ responsibilities
Fixed that for you.

No, thats wrong. AUR comes with extra things to consider, as you have just described yourself. That clearly can be considered a drawback compared to the use of pacman. That does not mean AUR should not be used in my opinion, but a drawback it still is.

Trilby wrote:

Just know what you are doing, and don't use them blindly.

Absolutely. Thats why I suggested to make the aspects of AUR packaged in regard to updates clear in the introduction of AUR in the wiki.

mpan wrote:

@markus_03
Judging by the reaction, I assume you came to Arch from Windows¹.

No rather from a heavily customized Ubuntu that I ripped apart and modified until I realised that the other way around (using a minimal System and add everything you need, like the arch way) is way better.

mpan wrote:

@markus_03
You're getting bad perspective.

I'm trying to get a realistic impression of the thechnologies I am using. Being aware of the implications and potential drawbacks is part of that.

mpan wrote:

@markus_03
AUR is advantage over how the software is being build without AUR.

I don't see the advantage compared to pacman (if thats what you mean)
Sure AUR adds a lot of opportunities to the existing stuff, but the way I see it a package manager like pacman is one of the greatest innovations in the modern world of operating systems. And having a system that can install and update your software automatically is clearly an advantage over a semiautomated setup (as long as the user has control and can validate every step of the way)

So yeah having AUR is great, but using it does not include the same advantages as using pacman.
I'm not saing that should keep users from using it, but when there is a comparable alternative for a package available in pacman, I would always prefer that way instead of a manual install, especially when regular updates are necessary.

And to come back to my original point; I think showing the complete picture in the wiki regarding the use of AUR should be desireable, since it allows users to make an educated decision. And pointing out that installing updated versions of AUR packages requires manual work, is clearly one important point.

ewaller · 2016-01-06 16:42:26

This is quickly devolving into a "bikeshed"

I believe the warning blocks in the USR wiki article say it all. Are these somehow not adequate to answer the your assertion. If your sole point is that the wiki does not explicitly state that it is up to the user to update their packages, then add it; it is a wiki. But, this does add to the argument against the uninformed use of helpers. Anyone who understands the AUR process and has built them by hand will know that the updates are not automatic. Those who don't understand how the AUR works are likely to be muisled by the obfuscation provided by certain AUR helpers. OTOH, as has been indicated, packer does a nice job of finding (some) things that need to be updated. Git and Mercurial based packages can be problematic as versions may not be determined until build time.

I thought your question had been well answered by firekage after which you seem to have circled around arguing against what you had asked to do in the first place.
I'm thinking this thread may be done, but I'll leave it open unless I've missed something.

Spyhawk · 2016-01-06 22:44:01

ewaller wrote:

OTOH, as has been indicated, packer does a nice job of finding (some) things that need to be updated.

Slightly OT, but I wouldn't recommend packer as a helper, never. It does source PKGBUILDs before the user has a chance to review them, unless the --preview flag is passed explicitly. Security wise, this is completely silly, even yaourt is better. Same goes for apacman and all packer's forks.

Last edited by Spyhawk (2016-01-06 22:47:30)

mpan · 2016-01-07 19:33:39

I smell a troll…

… but just in case the response is serious and markus_03 is truly believing what he's writting:

markus_03:
Please read what I have wrote. Carefully and with understanding. AUR is not advantage over pacman. AUR is advantage over how software is being built usually. The pacman way is not the usual method of building software.

markus_03 · 2016-01-08 13:39:09

mpan wrote:

I smell a troll…
… but just in case the response is serious and markus_03 is truly believing what he's writting:
markus_03:
Please read what I have wrote. Carefully and with understanding. AUR is not advantage over pacman. AUR is advantage over how software is being built usually. The pacman way is not the usual method of building software.

Agreed. Still I would consider pacman or any other packagemanager to be the preferred method of building/installing software.

Trilby · 2016-01-08 14:17:09

And when you build from the AUR you use makepkg (part of the pacman package, and part of the arch linux package management system) to build, and you use pacman (the package manager) to install it.

If you try to use a configure && make && make install series you will be circumventing the package management system and likely break things.

So what's the confusion? PKGBUILD (many of which can be found in the AUR) are the right way to install software that isn't in the repos.

markus_03 · 2016-01-13 16:38:16

Trilby wrote:

And when you build from the AUR you use makepkg (part of the pacman package, and part of the arch linux package management system) to build, and you use pacman (the package manager) to install it.
If you try to use a configure && make && make install series you will be circumventing the package management system and likely break things.
So what's the confusion? PKGBUILD (many of which can be found in the AUR) are the right way to install software that isn't in the repos.

The confusion was with the question wheter the PKGBUILD script also has some kind of update mechanism that triggers when running pacman -Syu.

I noticed the use of pacman in PKGBUILD but I wasn't sure about the update machanism.

Trilby · 2016-01-13 16:41:19

You simply run makepkg again any time you'd like to update the package. There are AUR helper programs that will tell you if there are updates for any of your currently installed AUR packages, but you can check this yourself on the AUR page for each package.

Failing to update an AUR package could never affect anything from the main repos (unless you use an AUR package to replace a main repo package) as nothing in the main repos can depend on AUR packages. So a failure to update an AUR package could only ever affect that package. So basically I rarely check my AUR packages for updates. If one of them acts up, then I check and rebuild.

Arch Linux

#1 2016-01-03 06:04:41

Updating AUR programms

#2 2016-01-03 06:07:00

Re: Updating AUR programms

#3 2016-01-03 06:17:30

Re: Updating AUR programms

#4 2016-01-03 07:19:35

Re: Updating AUR programms

#5 2016-01-03 08:05:06

Re: Updating AUR programms

#6 2016-01-03 23:27:33

Re: Updating AUR programms

#7 2016-01-04 10:23:28

Re: Updating AUR programms

#8 2016-01-04 12:57:52

Re: Updating AUR programms

#9 2016-01-05 08:43:53

Re: Updating AUR programms

#10 2016-01-06 16:21:19

Re: Updating AUR programms

#11 2016-01-06 16:42:26

Re: Updating AUR programms

#12 2016-01-06 22:44:01

Re: Updating AUR programms

#13 2016-01-07 19:33:39

Re: Updating AUR programms

#14 2016-01-08 13:39:09

Re: Updating AUR programms

#15 2016-01-08 14:17:09

Re: Updating AUR programms

#16 2016-01-13 16:38:16

Re: Updating AUR programms

#17 2016-01-13 16:41:19

Re: Updating AUR programms

Board footer