How do you get dependencies auto-satisfied with AUR?

Malvineous · 2011-04-02 06:45:24

Hi all,

I'm still having some difficulties setting up Arch as I try to move away from Gentoo. I like to use the "Awesome" window manager, which under Gentoo can be installed by running "emerge awesome". Under Arch "pacman -S awesome" doesn't work, so I guess this program is too obscure. I found some information about it being in "AUR", but it looks like I have to download and compile it myself (which I'm not overjoyed about, as this is one of the reasons why I want to move away from Gentoo - it takes too long to compile everything from source.)

I did however try to download the package but when I type "makepkg" it tells me there are a bunch of dependencies missing. Unfortunately I can't see how to get these dependencies downloaded, compiled and installed automatically like Gentoo does - there's no way I'm downloading, compiling and installing them one by one! (*That* was the reason I switched to Gentoo from Slackware...)

Could someone please point me in the right direction for this? Preferably with a single command I can type to install Awesome ;-) Thanks!

Allan · 2011-04-02 06:46:41

Look in the wiki for AUR helpers.

ngoonee · 2011-04-02 07:28:22

Malvineous wrote:

Could someone please point me in the right direction for this? Preferably with a single command I can type to install Awesome ;-) Thanks!

Expecting single-line behaviour isn't a good sign. Get familiar with the AUR before you use a helper, you won't regret it.

Malvineous · 2011-04-02 08:02:40

Why do you say that? It was single-line behaviour under Gentoo, I don't really want to go backwards - I'm switching away from Gentoo to save time, after all.

Thanks for the pointer to AUR helpers. Unfortunately there are dozens of them, and so far I have tried two of them and they both don't work (pkgman gives a syntax error and srcman requires a repo that is now dead) so it seems many of them are probably broken. Can you suggest one that will download an AUR package and all its dependencies and either install them or make them available to pacman to install?

blasse · 2011-04-02 08:46:02

makepkg may be used with -s switch, witch will install deps using pacman. If you need some automation try aurget (only for AUR) or clyde-git (as pacman replacement).
However, using AUR without understanding PKGBUILD can be very risky...

Malvineous · 2011-04-02 09:02:19

In what way? I get that they're shell scripts and they're sourced, but as long as I check them before they are used and the download URL is right, everything is fine, isn't it?

I've installed aurget and so far it seems to be working well. It picks up AUR-only dependencies as well as normal deps and generally seems to work the way I was hoping for! Thanks for the suggestion.

JBorneu · 2011-04-02 09:27:06

My favorite AUR helper is packer. It's simple, fast and it works, that's all I need.

admiralspark · 2011-04-02 10:14:52

Yaourt. Sure, it's bigger than other wrappers, but it works great for both official and AUR repo's, and has a nice and easy way to update AUR packages (yaourt -Sbu --aur). Just check the AUR list for awesome, and 'yaourt -S nameofawesome'!

ngoonee · 2011-04-02 14:26:55

Malvineous wrote:

Why do you say that? It was single-line behaviour under Gentoo, I don't really want to go backwards - I'm switching away from Gentoo to save time, after all.

If you really want to save time, just go Debian or something similar and be done with it.

Using wrappers without knowing what's underneath is a recipe for disaster. Murphy's Law states that that disaster will happen on the last day a project is due (or some similar catastrophic situation). Arch is not unstable, but neither is it zero-maintenance.

Awebb · 2011-04-02 14:50:42

I don't think the AUR is too complex to skip a few steps using a helper. Let's say you should have done it once
- makepkg -s
- resolve AUR deps manually, install them with the --asdeps switch of pacman
- Install the package with pacman -U
I've done it a couple of times and feel ready now to use a helper (yaourt, since clyde and bauerbill seem to refuse to work with the latest pacman). If anything breaks, I still know how to do it manually.

What I don't have a clue about is what makepkg does. Having a PKGBUILD for everything is too convenient, I thought about using Slackware for a while to learn such things. As long as I have access to the PKGBUILDs, I can not build up the necessary discipline to do it by foot :-D

EDIT:

On the other hand: When I first tried Arch, I relied on yaourt 100%. Most of the packages were uninstallable back then, I thought the whole AUR thing was a marketing fake that does not work as promised. When I came back to Arch a few months later, I tried the manual way, everything worked. Then I learned, that yaourt was having difficulties (since it was not actively developed anymore by that time).

Last edited by Awebb (2011-04-02 14:54:03)

uh8myzen · 2011-04-03 01:05:25

Malvineous wrote:

In what way? I get that they're shell scripts and they're sourced, but as long as I check them before they are used and the download URL is right, everything is fine, isn't it?
I've installed aurget and so far it seems to be working well. It picks up AUR-only dependencies as well as normal deps and generally seems to work the way I was hoping for! Thanks for the suggestion.

I had a hard time with AUR when I switched over, but not using a helper for a while helped me understand what was going on with the feedback in helpers and what was going on if there was a problem.

If you have a helper you like then stick with it, but if you are still looking for suggestions, I like packer... It works good for me, I'm not sure what others think.

I also find that pacman-color is handy to separate output.

Good luck, I hope it works out for you and that you find Arch as awesome as I do.

fsckd · 2011-04-03 01:46:27

aur helpers mask the underlying operations and behaviour

aur helpers assume you already know how aur works and can take over when something goes wrong

aur is tedious but simple; try makepkg by itself for a few install upgrade cycles and then switch to an aur helper

you may choose to build your own aur helper instead of using someone else's

Malvineous · 2011-04-10 10:35:57

Thanks for all the feedback. I've been using aurget for a while now and it's great! I'm not sure what everyone means by needing to fix things when they break - so far everything I have installed from AUR has worked perfectly. I have even grabbed the PKGBUILD files and modified them to make my own packages that can be built with makepkg. Maybe I'm missing something but having used Slackware for many years everything is all pretty straightforward. The only problem I have had is trying to get a mingw32 version of the Boost shared libraries to compile (this isn't in AUR so I'm making my own package), but the problems there are related to Boost compile errors and it's pretty easy to alter the commands and re-run makepkg.

@ngoonee: I have switched to Debian on my servers, but I prefer a more bleeding-edge distro on my desktop PC for my hobby coding, so I can get access to newer versions of things quicker. Gentoo was starting to lag behind in that respect, but it seems easier under Arch to compile your own package and upgrade the system supplied one if need be, something that was far too much effort under Gentoo.

So far the only annoyance I have experienced with Arch is that python3 is the default when the rest of the world expects "python" to run python2, but I'm slowly figuring out all the workarounds. Hopefully the Arch devs will eventually see the light and switch to what the rest of the Linux world seems to be standardising on ;-)

ngoonee · 2011-04-10 13:44:38

Malvineous wrote:

So far the only annoyance I have experienced with Arch is that python3 is the default when the rest of the world expects "python" to run python2, but I'm slowly figuring out all the workarounds. Hopefully the Arch devs will eventually see the light and switch to what the rest of the Linux world seems to be standardising on ;-)

I think you'll find it the other way around, that the 'rest of the Linux world' is going to be hopping on the bandwagon Arch has started with python3. There's been discussions on that both in these forums and the ML, public domain.

And no, there's no chance that python2 will be change back to the default python.

Awebb · 2011-04-10 16:29:19

If you have a look at some PKGBUILD files, you'll find out that this python transition is nothing that could not be fixed with a single line using sed.

fsckd · 2011-04-10 19:10:22

Malvineous wrote:

Thanks for all the feedback. I've been using aurget for a while now and it's great! I'm not sure what everyone means by needing to fix things when they break - so far everything I have installed from AUR has worked perfectly. I have even grabbed the PKGBUILD files and modified them to make my own packages that can be built with makepkg. Maybe I'm missing something but having used Slackware for many years everything is all pretty straightforward. The only problem I have had is trying to get a mingw32 version of the Boost shared libraries to compile (this isn't in AUR so I'm making my own package), but the problems there are related to Boost compile errors and it's pretty easy to alter the commands and re-run makepkg.

Twas an if. You give a generic query, receive a generic response. If something goes wrong, then it's not a bad idea to know how to fix it, no? Anyways, it looks like you already understand PKGBUILDs so we'll leave it at that.

So far the only annoyance I have experienced with Arch is that python3 is the default when the rest of the world expects "python" to run python2, but I'm slowly figuring out all the workarounds. Hopefully the Arch devs will eventually see the light and switch to what the rest of the Linux world seems to be standardising on ;-)

To add to the derail pile-on, upstream says "The Python 2.7 series is scheduled to be the last major version in the 2.x series before 2.x moves into an extended maintenance period." No reason to standardise on that. ;-)

Malvineous · 2011-04-17 06:20:42

fsckd wrote:

Twas an if. You give a generic query, receive a generic response. If something goes wrong, then it's not a bad idea to know how to fix it, no? Anyways, it looks like you already understand PKGBUILDs so we'll leave it at that.

Ouch - it was supposed to be a compliment at how well the whole system had been designed, that nothing had broken for me yet :-/

fsckd wrote:

To add to the derail pile-on, upstream says "The Python 2.7 series is scheduled to be the last major version in the 2.x series before 2.x moves into an extended maintenance period." No reason to standardise on that. ;-)

My issue isn't with standardising on old versions, it's with breaking backwards compatibility. Because the "python" command has long been used to run scripts in a particular language, introducing a new "python" command that runs scripts in effectively a different language seems a mistake. Especially when only new scripts will use the new language, having the command be "python3" instead seems to make sense. Then old scripts don't need to change, and new ones will work using the new interpreter name. I don't understand what benefit arises from making the "python" command run the new, mostly incompatible with old scripts, version.

It also irks me somewhat that I can't change the /usr/bin/python symlink to point to my preferred version. I was told that would break the system, which implies that Python3 scripts on the system are using /usr/bin/python instead of /usr/bin/python3, effectively making the same mistake all over again... I'm not wanting to blame anyone, just that to me it seems like a bad design choice. Perhaps because I don't fully understand the reasons behind it, but as yet I haven't seen any convincing arguments for it!

ngoonee · 2011-04-17 08:25:50

Basically, if you write scripts/installers that depend on a particular version of python you should check for it. /usr/bin/python pointing to the latest version of python makes sense because that's how every app works. /usr/bin/bash points to the latest available version of bash, /usr/bin/ls points to the latest version of ls.

IMO any non-trivial python apps should just call /usr/bin/python2 in any case....

Malvineous · 2011-04-17 12:19:50

I agree that *now* scripts should call /usr/bin/python2 if they need it, but because this requirement is a new development I still think it's a bad idea to break what has become established practice (that of calling /usr/bin/python to get a python2-compatible interpreter.) Yes bash and ls point to the latest versions of those tools, but they also maintain backward compatibility so there's no problem. In this respect, python3 is not really a new version of python2 - because of the significant changes it could be considered a slightly different language. Having /usr/bin/python link to the latest version of any Python is a bit like having /usr/bin/g++ link to the latest version of /usr/bin/gcc, because C and C++ are similar languages too :-)

ngoonee · 2011-04-17 13:28:15

Malvineous wrote:

I agree that *now* scripts should call /usr/bin/python2 if they need it, but because this requirement is a new development I still think it's a bad idea to break what has become established practice (that of calling /usr/bin/python to get a python2-compatible interpreter.) Yes bash and ls point to the latest versions of those tools, but they also maintain backward compatibility so there's no problem. In this respect, python3 is not really a new version of python2 - because of the significant changes it could be considered a slightly different language. Having /usr/bin/python link to the latest version of any Python is a bit like having /usr/bin/g++ link to the latest version of /usr/bin/gcc, because C and C++ are similar languages too :-)

g++ always links to the latest version of g++. C and C++ are different as decided by upstream, while python3 is 'the next python', not 'another python'. How different it is in practice isn't the deciding factor.

fsckd · 2011-04-17 15:17:16

Malvineous wrote:

fsckd wrote:
Twas an if. You give a generic query, receive a generic response. If something goes wrong, then it's not a bad idea to know how to fix it, no? Anyways, it looks like you already understand PKGBUILDs so we'll leave it at that.
Ouch - it was supposed to be a compliment at how well the whole system had been designed, that nothing had broken for me yet :-/

My bad.

Re python and backwards compatibility, I agree with you but ... uh ... them's the breaks. *shrugs* Upstream looks to regard python 3 as the next version and Arch follows upstream, etc. What ngoonee said.

Arch Linux

#1 2011-04-02 06:45:24

How do you get dependencies auto-satisfied with AUR?

#2 2011-04-02 06:46:41

Re: How do you get dependencies auto-satisfied with AUR?

#3 2011-04-02 07:28:22

Re: How do you get dependencies auto-satisfied with AUR?

#4 2011-04-02 08:02:40

Re: How do you get dependencies auto-satisfied with AUR?

#5 2011-04-02 08:46:02

Re: How do you get dependencies auto-satisfied with AUR?

#6 2011-04-02 09:02:19

Re: How do you get dependencies auto-satisfied with AUR?

#7 2011-04-02 09:27:06

Re: How do you get dependencies auto-satisfied with AUR?

#8 2011-04-02 10:14:52

Re: How do you get dependencies auto-satisfied with AUR?

#9 2011-04-02 14:26:55

Re: How do you get dependencies auto-satisfied with AUR?

#10 2011-04-02 14:50:42

Re: How do you get dependencies auto-satisfied with AUR?

#11 2011-04-03 01:05:25

Re: How do you get dependencies auto-satisfied with AUR?

#12 2011-04-03 01:46:27

Re: How do you get dependencies auto-satisfied with AUR?

#13 2011-04-10 10:35:57

Re: How do you get dependencies auto-satisfied with AUR?

#14 2011-04-10 13:44:38

Re: How do you get dependencies auto-satisfied with AUR?

#15 2011-04-10 16:29:19

Re: How do you get dependencies auto-satisfied with AUR?

#16 2011-04-10 19:10:22

Re: How do you get dependencies auto-satisfied with AUR?

#17 2011-04-17 06:20:42

Re: How do you get dependencies auto-satisfied with AUR?

#18 2011-04-17 08:25:50

Re: How do you get dependencies auto-satisfied with AUR?

#19 2011-04-17 12:19:50

Re: How do you get dependencies auto-satisfied with AUR?

#20 2011-04-17 13:28:15

Re: How do you get dependencies auto-satisfied with AUR?

#21 2011-04-17 15:17:16

Re: How do you get dependencies auto-satisfied with AUR?

Board footer