[arch-general] replacement for clyde
Hello! Some months ago I switched my desktop from Arch to FreeBSD to experiment a bit. Soon I may buy a new netbook and I believe that with ATI graphic, Arch is better choice, but looking at forums yesterday I saw that both bauerbill & clyde are gone. :-( Considering that decent package manager is very vital part of OS's ecosystem, I wonder what would be decent replacment having e.g. clyde-like features? Before clyde I used yaourt (which now has C-back end, afaik), tried paktahn (which has some quirks) and now I see pacaur (with cower). What can you recommend so I can read more about it? 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
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. you could pretty easily automate the main tasks of that in a script and voilà - you got your own aur helper. mar77i
On Fri, 19 Aug 2011 09:41:18 +0200 Martti Kühne <mysatyre@gmail.com> 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
Am Fri, 19 Aug 2011 08:49:03 +0200 schrieb Gour-Gadadhara Dasa <gour@atmarama.net>:
What can you recommend so I can read more about it?
yaourt or aurbuild Heiko
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 <gour@atmarama.net>:
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?
Hi, Am 19.08.2011 08:49, schrieb Gour-Gadadhara Dasa:
Before clyde I used yaourt (which now has C-back end, afaik), tried paktahn (which has some quirks) and now I see pacaur (with cower).
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
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" <karol@babioch.de> 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
On Fri, Aug 19, 2011 at 12:01 PM, Karol Babioch <karol@babioch.de> 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
2011/8/19 Cédric Girard <girard.cedric@gmail.com>:
On Fri, Aug 19, 2011 at 12:01 PM, Karol Babioch <karol@babioch.de> 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.
On Fri, Aug 19, 2011 at 3:11 PM, Thomas Dziedzic <gostrc@gmail.com> 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 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.
Well you're right, by itself the quality of the code is not an argument for the end-user. But when the lack of quality impacts speed and this can be supported by figures then I'd say it makes things completely different. That said, the situation may have evolved since and it may not be relevant anymore to throw these arguments against yaourt. -- Cédric Girard
2011/8/19 Cédric Girard <girard.cedric@gmail.com>
On Fri, Aug 19, 2011 at 3:11 PM, Thomas Dziedzic <gostrc@gmail.com> 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.
2011/8/19 Cédric Girard <girard.cedric@gmail.com>:
On Fri, Aug 19, 2011 at 3:11 PM, Thomas Dziedzic <gostrc@gmail.com> 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.
Definitely a valid opinion, as abstraction might be convenient or inexpedience to different audiences, which is why there really isn't a right answer. Programming also has this quality.
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 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.
Well you're right, by itself the quality of the code is not an argument for the end-user. But when the lack of quality impacts speed and this can be supported by figures then I'd say it makes things completely different.
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.
That said, the situation may have evolved since and it may not be relevant anymore to throw these arguments against yaourt.
-- Cédric Girard
On Fri, Aug 19, 2011 at 5:43 PM, Thomas Dziedzic <gostrc@gmail.com> 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
Excerpts from Cédric Girard's message of 2011-08-19 18:06:53 +0200:
On Fri, Aug 19, 2011 at 5:43 PM, Thomas Dziedzic <gostrc@gmail.com> 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.
Well, it was buggy as it couldn't handle some files, like packages with '+' in their names (example: lv2-c++-tools). Not sure this is fixed in the meantime. I use slurpy since a long time, it works with every package (it just has search, download and upload, no building included).
Le 19 août 2011 18:06, Cédric Girard <girard.cedric@gmail.com> a écrit :
On Fri, Aug 19, 2011 at 5:43 PM, Thomas Dziedzic <gostrc@gmail.com> 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 19 Aug 2011 10:43 -0500, Thomas Dziedzic wrote:
2011/8/19 Cédric Girard <girard.cedric@gmail.com>:
On Fri, Aug 19, 2011 at 3:11 PM, Thomas Dziedzic <gostrc@gmail.com> 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.
Definitely a valid opinion, as abstraction might be convenient or inexpedience to different audiences, which is why there really isn't a right answer. Programming also has this quality.
The problem that I've seen is that some users start treating yaourt as THE package manager and start making bug reports, when the bug exists in yaourt rather than pacman.
On Fri, Aug 19, 2011 at 10:11 AM, Thomas Dziedzic <gostrc@gmail.com> 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 11:08 AM, Vitor Eiji Justus Sakaguti <vitoreiji0@gmail.com> wrote:
# Better yaourt yaourt () { if [[ $# == 0 ]] then /usr/bin/yaourt -Sayu else /usr/bin/yaourt $@ fi }
For something more terse: yaourt () { yaourt ${@:--Sayu}; } -- “The journey is more important than the destination—that’s part of life, if you only live for getting to the end, you’re almost always disappointed.” Donald E. Knuth
On Fri, Aug 19, 2011 at 2:13 PM, Kazuo Teramoto <kaz.rag@gmail.com> wrote:
On Fri, Aug 19, 2011 at 11:08 AM, Vitor Eiji Justus Sakaguti <vitoreiji0@gmail.com> 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 12:28 PM, Vitor Eiji Justus Sakaguti <vitoreiji0@gmail.com> wrote:
On Fri, Aug 19, 2011 at 2:13 PM, Kazuo Teramoto <kaz.rag@gmail.com> wrote:
On Fri, Aug 19, 2011 at 11:08 AM, Vitor Eiji Justus Sakaguti <vitoreiji0@gmail.com> 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.
this isn't doing quite what you think. ${@:--Sayu} is functionally equivalent to ${1:--Sayu} ... it's only testing the first argument though it probably works fine for the use case. and you can use the bash keyword `command` to suppress function lookup and avoid a loop, but still use $PATH. -- C Anthony
On Fri, Aug 19, 2011 at 7:53 PM, C Anthony Risinger <anthony@xtfx.me> 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 Fri, 19 Aug 2011 12:01:42 +0200 Karol Babioch <karol@babioch.de> 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? As far as I can remember there were some glitches with clyde, but I haven't heard anything bad about yaourt so far ;).
I was using yaourt since my very beginning of using Arch, but it was (is) broken not being able to properly handle deps for Haskell packages. (check http://archhaskell.wordpress.com/) and that's why I switched to clyde. 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
On Fri, Aug 19, 2011 at 8:49 AM, Gour-Gadadhara Dasa <gour@atmarama.net> wrote:
Soon I may buy a new netbook and I believe that with ATI graphic, Arch is better choice, but looking at forums yesterday I saw that both bauerbill & clyde are gone. :-(
Considering that decent package manager is very vital part of OS's ecosystem, I wonder what would be decent replacment having e.g. clyde-like features?
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." SCNR :P
On Fri, 19 Aug 2011 13:22:16 +0200 "Andre \"Osku\" Schmidt" <andre.osku.schmidt@googlemail.com> 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
On Sat, Aug 20, 2011 at 01:51, Gour-Gadadhara Dasa <gour@atmarama.net> wrote:
On Fri, 19 Aug 2011 13:22:16 +0200 "Andre \"Osku\" Schmidt" <andre.osku.schmidt@googlemail.com> 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!
Am Sat, 20 Aug 2011 12:17:40 -0500 schrieb Myra Nelson <myra.nelson@hughes.net>:
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
On Sat, Aug 20, 2011 at 12:30, Heiko Baums <lists@baums-on-web.de> wrote:
Am Sat, 20 Aug 2011 12:17:40 -0500 schrieb Myra Nelson <myra.nelson@hughes.net>:
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!
El sábado 20 de agosto de 2011, Myra Nelson <myra.nelson@hughes.net> escribió:
To me using an AUR helper to install the deps automattically is like blindly doing this "pacman -syu" [...]
yaourt tells you every dependency it needs to install and stops at every single package, letting you view/edit each PKGBUILD and install script, so it is pretty far from blind. I wouldn't use it otherwise. I have not used any other helper (only bauerbill, which no longer works) so I can not speak of them.
Am Sun, 21 Aug 2011 13:57:47 +0200 schrieb José M. Prieto <jmprieto@gmx.net>:
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
On Sun, 21 Aug 2011 14:55:47 +0200 Heiko Baums <lists@baums-on-web.de> wrote:
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.
I prefer to have them connected. :-) 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
participants (17)
-
Andre "Osku" Schmidt
-
Buce
-
C Anthony Risinger
-
Cédric Girard
-
Gour-Gadadhara Dasa
-
Heiko Baums
-
José M. Prieto
-
Karol Babioch
-
Kazuo Teramoto
-
Loui Chang
-
Martti Kühne
-
Myra Nelson
-
Nicholas MIller
-
Philipp Überbacher
-
Thomas Dziedzic
-
tuxce
-
Vitor Eiji Justus Sakaguti