On Fri, 19 Aug 2011 09:41:18 +0200 Martti Kühne wrote:

I'm pretty content with bruenig's packer myself, but I recommend you read the wiki entry about how to use ABS - all aur helpers are in a first stage about automation of downloading source tarballs and makepkg -i.

Thank you. I'll take a look at packer as well. Otoh, I have some experience with Arch using it since sumer '07 till the spring '11. Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Excerpts from Heiko Baums's message of 2011-08-19 10:23:27 +0200:

Am Fri, 19 Aug 2011 08:49:03 +0200 schrieb Gour-Gadadhara Dasa :

...

What can you recommend so I can read more about it?

yaourt or aurbuild

Heiko

Since slurpy seems to have gone missing I need a new helper. I tried aurbuild but I don't quite get that thing. Where does it store the packages it has built? How can I check them with namcap before installing?

Before clyde I used yaourt (which now has C-back end, afaik), tried

I use yaourt without any problems. Used Clyde prior. And I don't notice any major differences On Aug 19, 2011 7:02 PM, "Karol Babioch" wrote: Hi, Am 19.08.2011 08:49, schrieb Gour-Gadadhara Dasa: paktahn

(which has some quir... I'm using yaourt and am now wondering what is wrong with it, when you actually know of it, and don't want to use it ;)? Is there any flaw so far? As far as I can remember there were some glitches with clyde, but I haven't heard anything bad about yaourt so far ;).

Best regards, Karol Babioch

2011/8/19 Cédric Girard :

On Fri, Aug 19, 2011 at 12:01 PM, Karol Babioch wrote:

...

I'm using yaourt and am now wondering what is wrong with it, when you actually know of it, and don't want to use it ;)? Is there any flaw so far?

At the time of packer first release (January 2010), yaourt was slow and had some awful code in it. yaourt also made the choice to accept arguments where it add no value (like yaourt -R, only delegating to pacman).

I haven't tested yaourt since. I was using packer and now have switch to pacaur. Both are fine but I find pacaur handling in a better way dependency resolution on AUR packages.

-- Cédric Girard

I've used yaourt for a couple of years now. It has always worked for me for the most part, and having a common command for everything is very convenient for me. alias y=yaourt and you have one of the simplest ways to do a complete update of your system, y -Syua I always ignored people's comments because the majority argues that it is "either too slow", or the "code is ugly". These same people would probably be horrified looking through vim's code :P These points alone do not make a very convincing argument for me, which is why I grew numb to them.

2011/8/19 Cédric Girard

On Fri, Aug 19, 2011 at 3:11 PM, Thomas Dziedzic wrote:

...

I've used yaourt for a couple of years now. It has always worked for me for the most part, and having a common command for everything is very convenient for me. alias y=yaourt and you have one of the simplest ways to do a complete update of your system, y -Syua

I understand this may seems convenient to some. For me it is just useless and just abstract things from the user. If I want to run pacman -Rs foo, why would I be motivated to do yaourt -Rs foo instead if yaourt only call pacman -Rs foo ?

I don't like any overlap of functionality between pacman and my AUR helper, too, and I use cower for that purpose. You still have to do makepkg and pacman -U (or makepkg, repo-add and pacman -Syu) manually, but that's my preference anyhow, and it's easily scripted.

On Fri, Aug 19, 2011 at 5:43 PM, Thomas Dziedzic wrote:

I agree that your arguments have a valid point of view all the way up to this point where you lost me. For me, "lack of quality" is in the same category as "lack of quality impacts speed" For example, lets have the same badly written algorithm compiled with no optimization and the other being compiled with -O999 ZOMG!! It doesn't matter to me if one ruins your system faster, it will still do the same thing. This is why I think the "lack of quality impacts speed" issue being completely different from "lack of quality" is invalid.

I will try to explain my point with an example. Take a bash script which needs to find some string into a file. Let's do this the ugly way: echo $(cat $file) | grep -q "%PROVIDES%.*$1" Let's do this the correct way: grep -q "%PROVIDES%.*$1" $file If both take the same resources to execute, you may say: OK, the first one is ugly but I don't really care because both give the same result and there is no performance impact. Now, if the first one appears to be way slower than the second one, the situation is different because not only it impacts the developer (complex code hard to understand and maintains) but it also impacts the end user (have to wait longer than needed). This example was one real example taken from yaourt at the state it was in January 2010. There is nothing ugly in the way it will not work or break your system. It was just ugly and slow code. -- Cédric Girard

Le 19 août 2011 18:06, Cédric Girard a écrit :

On Fri, Aug 19, 2011 at 5:43 PM, Thomas Dziedzic wrote:

...

I agree that your arguments have a valid point of view all the way up to this point where you lost me. For me, "lack of quality" is in the same category as "lack of quality impacts speed" For example, lets have the same badly written algorithm compiled with no optimization and the other being compiled with -O999 ZOMG!! It doesn't matter to me if one ruins your system faster, it will still do the same thing. This is why I think the "lack of quality impacts speed" issue being completely different from "lack of quality" is invalid.

I will try to explain my point with an example. Take a bash script which needs to find some string into a file. Let's do this the ugly way: echo $(cat $file) | grep -q "%PROVIDES%.*$1" Let's do this the correct way: grep -q "%PROVIDES%.*$1" $file

This is a wrong example :) Those commands are different. "echo $(cat file) |" provides an input without "\n"

If both take the same resources to execute, you may say: OK, the first one is ugly but I don't really care because both give the same result and there is no performance impact. Now, if the first one appears to be way slower than the second one, the situation is different because not only it impacts the developer (complex code hard to understand and maintains) but it also impacts the end user (have to wait longer than needed).

This example was one real example taken from yaourt at the state it was in January 2010. There is nothing ugly in the way it will not work or break your system. It was just ugly and slow code.

-- Cédric Girard

On Fri, Aug 19, 2011 at 10:11 AM, Thomas Dziedzic wrote:

I've used yaourt for a couple of years now. It has always worked for me for the most part, and having a common command for everything is very convenient for me. alias y=yaourt and you have one of the simplest ways to do a complete update of your system, y -Syua

A few months ago I wrote a little bash function to put in my bashrc. Maybe you'll like it. # Better yaourt yaourt () { if [[ $# == 0 ]] then /usr/bin/yaourt -Sayu else /usr/bin/yaourt $@ fi } So yaourt with no arguments updates my system. I use it about twice a day. Vitor

On Fri, Aug 19, 2011 at 2:13 PM, Kazuo Teramoto wrote:

On Fri, Aug 19, 2011 at 11:08 AM, Vitor Eiji Justus Sakaguti wrote:

...

   # Better yaourt    yaourt () {        if [[ $# == 0 ]]        then            /usr/bin/yaourt -Sayu        else            /usr/bin/yaourt $@        fi    }

For something more terse:

yaourt () { yaourt ${@:--Sayu}; }

Looks nice, thanks! But it should be yaourt () { /usr/bin/yaourt ${@:--Sayu}; } or we are trapped in and endless loop. Vitor

On Fri, Aug 19, 2011 at 7:53 PM, C Anthony Risinger wrote:

and you can use the bash keyword `command` to suppress function lookup and avoid a loop, but still use $PATH.

oh that's much prettier. thx. been relying on $(which $0) for the $PATH part. mar77i

On Sat, Aug 20, 2011 at 01:51, Gour-Gadadhara Dasa wrote:

On Fri, 19 Aug 2011 13:22:16 +0200 "Andre \"Osku\" Schmidt" wrote:

...

pacman is the package manager.

and AUR is "Unsupported packages are user produced content. Any use of the provided files is at your own risk."

I'm very well aware of it. However, when I install package with AUR, my system does not make any distinction between it and other stuff from 'official' repos - that's why I want to be able to install from AUR, having proper deps resolution etc. hoping that 'package manager/AUR_helper' have trust that I know what I'm doing. ;)

Sincerely, Gour

-- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu)

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

Having this distinction and having the proper deps installed is easy using cower unless the deps are in the AUR: cower -d {packagename} will download the necessary files into a directory /{pwd}/{packagename/ cower -vu will list any updates from AUR cower -vud will download the necessary update PKGBUILD etc and won't overwrite and existing directory. cower -vudf will download the necessary update PKGBUILD etc and will overwrite and existing directory. cd {packagename} makepkg pacu packagename This insures your deps are installed unless the deps are in the AUR. In which case one should investigate the deps first instead of letting a package manager blindly download and install unsupported deps that might break some portion of your system (I've never used yaoart so if I'm wrong about this point excuse me). For me this is a safer way to manage AUR packages. Ciao for now. Myra -- Life's fun when your sick and psychotic!

On Sat, Aug 20, 2011 at 12:30, Heiko Baums wrote:

Am Sat, 20 Aug 2011 12:17:40 -0500 schrieb Myra Nelson :

...

This insures your deps are installed unless the deps are in the AUR.

As far as I know yaourt installs the deps which are in the AUR automatically and writes them into the package database, so that pacman is aware of those dependencies, too. So that they are automatically uninstalled, too, if the main package is uninstalled, also if it's uninstalled by pacman instead of yaourt.

And the PKGBUILDs and .install files can, of course, be viewed first.

Heiko

That's true, but I prefer to do my own research and install the deps myself. Yes it's a longer process, but then I'm sure any mistakes are mine. To me using an AUR helper to install the deps automattically is like blindly doing this "pacman -syu" without following arch linux mailing lists, reading any arch news posts, or not paying attention to any warning messages then saying yes when asked if you want to continue with the updates. That's just my personal opinion born from making some mistakes along the way, however to each his own. Myra -- Life's fun when your sick and psychotic!

Am Sun, 21 Aug 2011 13:57:47 +0200 schrieb José M. Prieto :

I have not used any other helper (only bauerbill, which no longer works) so I can not speak of them.

If someone wants to have pacman and AUR totally separated and don't want a wrapper for both at the same time, aurbuild is a good alternative for yaourt. Heiko