Yaourt Installer

UsrCletus · 2016-12-30 05:54:56

I created this yaourt-install package out on github, and was hoping I could get some feedback. Basically it's for newbies to be able to install yaourt. The URL is as follows: https://github.com/usrcletus/yaourt-install

You can download and install the package by doing the following:

$ git clone https://github.com/usrcletus/yaourt-install
$ cd yaourt-install
$ ./yaourt-install

It satisfies dependencies, etc. Please try and break it and/or give me feedback?

jasonwryan · 2016-12-30 06:13:09

Moving to Community Contributions.

Aside: this script will do the Arch community no favours; there are already far too many people that use yaourt (the worst of all the AUR helpers) without any idea of how pacman or makepkg actually work. Making it "easier" for them to install such a defective application has no upside.

eschwartz · 2016-12-30 06:54:40

1) Don't cross-post (to https://bbs.archlinux.org/viewtopic.php … 4#p1679784)

2) That script is even stupider than using the archlinuxfr binary repository which also allows idiots to install yaourt without knowing what they are doing.

3) The weird abstraction and nested functions which accomplish nothing instantly qualify that script as revolting. The fact that you don't know how to use return codes and instead use variables/grep to find out whether a command failed is also pretty bad, you should probably learn to use HEREDOCs, you should definitely learn to use arrays, inconsistent quoting for filepaths you don't control, a useless function to check whether people are running a kernel with "ARCH" in the uname (which has nothing to do with whether they run Arch Linux)... I could go on, but, well, that would encourage you to improve this script, which implies it should continue to exist.

Last edited by eschwartz (2016-12-30 07:02:42)

Docbroke · 2016-12-30 07:05:48

how it is easier than using, below for packag-querry and yaourt,

 git clone "aur path to yaourt"; cd "yaourt" ; makepkg -sri

or manually downloading PKGBUILDS and using makepkg -sri ?

As one can see that installing your script requires almost similar steps.

and there is no point in promoting yaourt, if aur-helper is needed, I would use pacaur.

eschwartz · 2016-12-30 07:08:35

Docbroke, pacaur has its own problems -- but pacaur vs. yaourt is neither here nor there.

Promoting anything, even the fad-ish pacaur, as an auto-install without invoking the user's brain, is a terrible idea. Promoting pacaur in this manner would even be worse than yaourt (for purely cultural reasons).

Xyne · 2016-12-30 07:30:07

@UsrCletus
Community contributions are appreciated but this will likely receive a lot of discouraging feedback. As others have pointed out above, this script is overall detrimental to the community as it promotes several bad habits that we would like our users to avoid.

A few technical notes about the script as well:

You should use arrays and properly quote your variables as mentioned above.
Instead of piping the full output of "pacman -Q" to grep to check for each dependency (which involves multiple unnecessary system calls), use
```
pacMissing=(pacman -T $pacDependencies)
missingCount=${#pacMissing[@]}
```
and update the rest accordingly. Check pacman's help messages and man page to learn about the different options available (e.g. -T, -Qq).
Your script installs the missing dependencies explicitly instead of as dependencies. You can use the "--asdeps" option, but you really shouldn't be manually installing repo deps with pacman. Use makepkg's option to install missing dependencies when building packages. Base-devel should be installed already by anyone building packages. Incidentally, this highlights the point made above: users should familiarize themselves with pacman and makepkg before messing around with AUR helpers, especially those who want to mess around with wrapper scripts.
Instead of check_distro, you should probably just check if pacman and/or makepkg are installed. Then again, if a user is trying to run your script on a non-Arch system them that user really shouldn't be messing around with automated yaourt installations. It's like greasing up the trigger of a gun to make it easier for a toddler to pull it.
It's probably a bad idea to encourage users to edit the sudoers file based on the instructions of a random script they've downloaded and run on their system.

UsrCletus · 2016-12-30 07:46:04

Eschwartz (From your comments in the duplicate thread which was killed):

Sorry for the crossposting. I am fairly new to the forums and didn't see the other thread. Not sure if this was the right way to post this, or if I should have used the other thread. Anyways, I appreciate the feedback, but a little less condescension would be nice. Additionally, I am not really interested in your opinion on whether or not the script should exist. I am sure there are many users new to Arch that would benefit from something like this.

Completely useless response, that has absolutely no value to this thread:

"That script is even stupider than using the archlinuxfr binary repository which also allows idiots to install yaourt without knowing what they are doing."

This is not helpful at all, was not asked for, and is rude. That being said, if you wish to be condescending and rude towards my work, please provide some examples while doing so. For example:

"The weird abstraction and nested functions which accomplish nothing instantly qualify that script as revolting."

Please show me a function that does nothing. Additionally, a nested function is a function within a function. Nowhere in my code does this exist. "Weird" is an opinion, and completely useless for this discussion.

The fact that you don't know how to use return codes and instead use grep to find out whether a command failed is also pretty bad, you should probably learn to use HEREDOCs, you should definitely learn to use arrays, inconsistent quoting for filepaths you don't control, a useless function to check whether people are running a kernel with "ARCH" in the uname (which has nothing to do with whether they run Arch Linux).

Just because I didn't choose to use a specific method/convention to accomplish a task doesn't mean I don't know how. You make a lot of assumptions here which are simply rude. Frankly, the only thing about your entire response that was even REMOTELY helpful was the following:

"inconsistent quoting for filepaths you don't control, a useless function to check whether people are running a kernel with "ARCH" in the uname (which has nothing to do with whether they run Arch Linux)."

Even the "helpful" section i've listed above is full of condescending remarks. A better way to contribute/provide feedback would have been as follows:

1. A HEREDOC or an Array may have been helpful in the following instances (provide instance(s)).
2. Inconsistent quoting for filepaths you don't control in the following example: (provide example). How to fix?
3. Your function to check the distribution will fail in scenarios X and Y (provide scenarios).

Out of your entire response there is little to Zero helpful information at all. Why even reply to my post? Just to put me down? Please move on, or attempt to be helpful in my growth. Anything outside of that is completely useless and will fall on deaf ears.

x33a · 2016-12-30 07:52:02

@UsrCletus, I have moved your post to the relevant thread. Note: This thread has not been killed.

Docbroke · 2016-12-30 09:11:34

Eschwartz wrote:

Docbroke, pacaur has its own problems -- but pacaur vs. yaourt is neither here nor there.
Promoting anything, even the fad-ish pacaur, as an auto-install without invoking the user's brain, is a terrible idea. Promoting pacaur in this manner would even be worse than yaourt (for purely cultural reasons).

I have no intention of promoting any aur-helper, however I intend to discourage users from using yaourt

I am sure you are aware of this https://wiki.archlinux.org/index.php/AU … ison_table,

Afterall everything has it's own problems, it is about choosing the lesser evil.

Trilby · 2016-12-30 11:58:31

Let's all keep the rules in mind. Many of us take our code personally, leading harsh critiques of the code to feel like personal attacks - and as a result there can sometimes be a fine line between the two. Harsh critiques of code are welcome - but more effective if presented gracefully (in theory, but see next paragraph). But lets make sure the code itself is the target of feedback.

UserCletus, Xyne presented a much more targetted set of critiques. But yet you focused on the post that aggravated you and ignored Xyne's comments. This is why I said "in theory" graceufully presented critiques are more effective. In reality, human nature draws us to the extremes. If you want this thread to be productive, ignore that which would inflame it, and respond to that which is presented more fairly.

Scimmia · 2016-12-30 13:59:02

UsrCletus wrote:

I am sure there are many users new to Arch that would benefit from something like this.

This is where almost everyone will disagree with you. It would benefit new users to learn how the AUR works; it does them and the community a great disservice do it for them. When things go wrong, they will be totally lost and seek help here for trivial things they should know.

oliver · 2016-12-30 14:05:07

Just something that bothers me in general...

grep $(whoami) /etc/group|grep wheel |wc -l

grep has a -c (for count) flag

But this could also be written as

groups $(whoami) | grep -c wheel

Other than that, don't get discouraged by blunt criticism, you'll write better scripts if you take it on board

And double-quote your variables

Last edited by oliver (2016-12-30 14:06:13)

ayekat · 2016-12-30 14:24:41

Assuming that a user needs to be part of the `wheel` group is an unfortunate assumption you make (even if applicable in most cases). Better use `sudo -l` (check the man page) for that job.
Checking whether the list of installed packages from the `base-devel` group is non-empty will not work, since there are packages in there that are also part of the `base` group (11 at the time of this writing). ninja'd edit by Trilby below
This has already been pointed out, but even more specifically: linux-lts does not contain `ARCH` in its `uname -a` output.

For the last point, I think the distro checking is entirely unnecessary, given that the fundamental design issue of your script is the fact that you target the wrong distribution. So here I have to disagree with Xyne and say that if this script is also wrong for other distributions, it's their own problem.

Last edited by ayekat (2016-12-30 14:31:02)

Trilby · 2016-12-30 14:30:10

There is also no need to check what is installed. You know what is needed - just ensure those are installed:

pacman -S --needed base-devel

eschwartz · 2016-12-30 16:26:17

UsrCletus wrote:

"That script is even stupider than using the archlinuxfr binary repository which also allows idiots to install yaourt without knowing what they are doing."
This is not helpful at all, was not asked for, and is rude. That being said, if you wish to be condescending and rude towards my work, please provide some examples while doing so. For example:

AFAIK there is not actually any sort of rule about respecting other peoples' code, just the people themselves. And I can live with your disappointment in my rudeness at your code.

Automatic installers for AUR helper that aid idiots in installing AUR helpers without actually learning what they are doing, is exactly the kind of thing that tends to motivate me to be rude. Because its effect is to (attempt to) destroy the Arch Linux community.

"The weird abstraction and nested functions which accomplish nothing instantly qualify that script as revolting."
Please show me a function that does nothing. Additionally, a nested function is a function within a function. Nowhere in my code does this exist. "Weird" is an opinion, and completely useless for this discussion.

It is the splitting up into functions that is useless. Calling functions which call other functions which call other functions, makes the script harder to read... and in this case of making functions to do one-liner tasks, that doesn't aid the control flow or maintenance at all, which means factoring it out accomplished nothing practical, and simply served to obfuscate what is going on.

Abstracting one-liners out into functions is pretty weird in my book. But if you want to call it a meaningless personal opinion, go right ahead.

The fact that you don't know how to use return codes and instead use grep to find out whether a command failed is also pretty bad, you should probably learn to use HEREDOCs, you should definitely learn to use arrays, inconsistent quoting for filepaths you don't control, a useless function to check whether people are running a kernel with "ARCH" in the uname (which has nothing to do with whether they run Arch Linux).
Just because I didn't choose to use a specific method/convention to accomplish a task doesn't mean I don't know how. You make a lot of assumptions here which are simply rude. Frankly, the only thing about your entire response that was even REMOTELY helpful was the following:

I meant what I said. You should learn to use them. It doesn't matter whether you know they exist, if you don't use them. There is my advice -- learn to use what you know.

"inconsistent quoting for filepaths you don't control, a useless function to check whether people are running a kernel with "ARCH" in the uname (which has nothing to do with whether they run Arch Linux)."
Even the "helpful" section i've listed above is full of condescending remarks. A better way to contribute/provide feedback would have been as follows:
1. A HEREDOC or an Array may have been helpful in the following instances (provide instance(s)).
2. Inconsistent quoting for filepaths you don't control in the following example: (provide example). How to fix?
3. Your function to check the distribution will fail in scenarios X and Y (provide scenarios).

The fact that this was an automated yaourt installer likely influenced my tone.

Out of your entire response there is little to Zero helpful information at all. Why even reply to my post? Just to put me down? Please move on, or attempt to be helpful in my growth. Anything outside of that is completely useless and will fall on deaf ears.

Yes, I can tell you don't want to hear how unwise an automated yaourt installer is...

But really, this script can be simplified to rewritten from scratch as:

cd /tmp; sudo pacman -S --needed base-devel git && for i in package-query yaourt; do (git clone https://aur.archlinux.org/$i && cd $i && makepkg -sri); done

Just do what you want to do, use idempotent utilities as available (because they are available), and if it turns out someone tried running this on a non-Arch Linux system, the lack of both pacman and makepkg should be sufficient notice that running Arch Linux-specific scriptlets copied from an Arch Linux website with the loud warning "This installs yaourt on your Arch Linux computer" only makes sense on an Arch Linux computer.
Protip: attempting to use sudo already gives you a useful error message. Multiplying the size of the command from a one-liner to an eight-line script just to explain the historical and practical significance of sudo is inefficient for the purpose at hand. One-liners don't need complex debugging or embedded documentation, external documentation serves far better.

Last edited by eschwartz (2016-12-30 19:32:35)

Xyne · 2016-12-30 19:23:31

ayekat wrote:

For the last point, I think the distro checking is entirely unnecessary, given that the fundamental design issue of your script is the fact that you target the wrong distribution. So here I have to disagree with Xyne and say that if this script is also wrong for other distributions, it's their own problem.

In that post, I used the term "non-Arch system" very loosely and admittedly ambiguously to mean a system without pacman. If a user is so lost that they are trying to install yaourt on a system without pacman, they really shouldn't be running random scripts that they've downloaded from the internet.

Eschwartz wrote:

AFAIK there is not actually any sort of rule about respecting other peoples' code, just the people themselves.

Criticism of code leads to improvements and is encouraged. It should nevertheless be done without a hostile tone. Terms such as "idiots", "even stupider" and "The fact that you don't know how to ... is also pretty bad." express personal opinions and disparage others in what should be a technical discussion.

As a rule of thumb, assume that bad technical choices have been made out of simple ignorance and not wilful disregard for best practices. "Are you familiar with x?" is much more conducive to fruitful discussion than "Wtf didn't you use x?" with the implication that the user is an idiot for not using the "oh-so-obvious" x, which is really only obvious with experience. Treat the user as a teacher would treat a student.

If the user continues to ignore good advice, then you can dismiss him/her as an idiot

UsrCletus · 2016-12-30 19:30:34

Thanks for everyone for the more encouraging feedback. I'll take the technical items that were pointed out to me and make an update this evening, to get some more feedback.

Arch Linux

#1 2016-12-30 05:54:56

Yaourt Installer

#2 2016-12-30 06:13:09

Re: Yaourt Installer

#3 2016-12-30 06:54:40

Re: Yaourt Installer

#4 2016-12-30 07:05:48

Re: Yaourt Installer

#5 2016-12-30 07:08:35

Re: Yaourt Installer

#6 2016-12-30 07:30:07

Re: Yaourt Installer

#7 2016-12-30 07:46:04

Re: Yaourt Installer

#8 2016-12-30 07:52:02

Re: Yaourt Installer

#9 2016-12-30 09:11:34

Re: Yaourt Installer

#10 2016-12-30 11:58:31

Re: Yaourt Installer

#11 2016-12-30 13:59:02

Re: Yaourt Installer

#12 2016-12-30 14:05:07

Re: Yaourt Installer

#13 2016-12-30 14:24:41

Re: Yaourt Installer

#14 2016-12-30 14:30:10

Re: Yaourt Installer

#15 2016-12-30 16:26:17

Re: Yaourt Installer

#16 2016-12-30 19:23:31

Re: Yaourt Installer

#17 2016-12-30 19:30:34

Re: Yaourt Installer

Board footer