"there aren't nearly as many packages in the repos/AUR as X distro"

McQueen · 2008-01-31 06:24:03

zodmaner wrote:

IMHO, I find it hard to believe that Arch userbase needs yaourt to find it attractive to use AUR. Yes, yaourt make it easier to use AUR, but it is not necessary to use it.

And as soon as you put it in the official repo then next somebody wants a GUI for the darn thing...it is always something. The reasons for not providing these type of tools in the repo are well grounded legally, and it provides the AUR with the large amount of anonymity that it currently enjoys. It is a win-win.

iphitus · 2008-01-31 08:22:38

yaourt is not going into the repos in any form.

I raised this among the developers not long ago, and it's not happening. Discuss if you want, but I doubt it'll change the position of the developers.

Given that, best way would be to increase awareness of the AUR after install, possibly just a post ISO install readme, or better, some reading material for people to browse _during_ the install from ISO/ftp.

James

tomk · 2008-01-31 10:30:43

jacko wrote:

Lack of AUR awareness/understanding. People don't know it's there, thus packages appear unavailable.
Yep, I'd say that's about it. But in no way have you busted the myth on why it perpetuates till u take care of the above situation.

It's mentioned in the "Welcome to Arch!" blurb at the very top of our home page. There's a link to it at the top of every page in *.archlinux.org. There is extensive information about it in the wiki. There are AUR-relevant boards in the forum. There is a dedicated AUR mailing list.

Any suggestions you would like to make to help increase AUR awareness and understanding will be most welcome.

tigrmesh · 2008-01-31 16:20:10

iphitus wrote:

best way would be to increase awareness of the AUR after install [...] some reading material for people to browse _during_ the install from ISO/ftp.

Putting something in the install or post-install guide is a great idea. I was intimidated by the AUR and didn't understand that it's an integral part of Arch.

Zer0 · 2008-01-31 17:12:20

1) Arch has plenty of packages if you include AUR's unsupported repo so the "X distro has more" argument is bogus. If I were to come across a package that wasn't in Arch I'll just write a PKGBUILD and submit it for all to use. Any person who understands some scripting/programming could do this easily. People who use AUR and don't understand what they are looking at in a PKGBUILD should not use the unsupported repo anyways as that would be unsafe, and a tool like yaourt makes it just to easy to use AUR without learning about it first.

2) The real issue is more like "X distro has more packages that are easier to install". Reading above I have yet to see anyone really mention a missing package in Arch. Arch has all the packages a person should need, it just wont "hold your hand" when installing from say AUR. Arch isn't that "Hold your hand" distro.. it's a "read and learn" distro.. people who are willing to learn for themselves are the audience! As mentioned in a couple posts already, there are always users who are unsure of AUR at first but they "come around" once they learn and understand it.

3) They bigger issue is the problems with how unsupported is maintained as a whole. PKGBUILD's are created by users, but there needs to be easier/more ways to keep those PKGBUILD's and their contributers in check! For instance I wanted to take over a package that had been unmaintained for 2+ years in AUR and flagged out of date. To do this I had to join the AUR-general Mailing list to contact a TU. I don't care for mailing lists, but I did it anyway.

We need solid guidelines of.. What methods to take when a package should be forcefully orphaned, how long do we wait for the contributer to update a package before it can be forcefully orphaned, etc.. If you can find answers to these questions in the WIKI.. I dare you to show me Fixing these issues will make it easier for us PKGBUILD contributers to "keep the ball rolling" in unsupported and the complaints of "this package wont compile, new version, etc.." wont be an issue. Unsupported is that extra piece to the "more packages puzzle" and I feel it's starting to slack a little.

EDIT: and another thing.. Do TU's flag packages as safe anymore? I know their pretty busy but it seems that packages aren't being flagged safe as often as they used to be. Maybe another special kind of TU's could be added to the mix. These "safe checking" TU's would be TU level 1 and then could move up to TU level 2 (Maintainers) after awhile. Just an idea which might help ease the pain of those who are scared of AUR at first glance. There are soooo many PKGBUILD's that could be flagged as safe.

Last edited by Zer0 (2008-01-31 17:21:33)

byte · 2008-01-31 18:04:04

Zer0:
About safe-flagging -> http://projects.archlinux.org/git/?p=au … 3b5015bc6a

jacko · 2008-01-31 19:25:46

Any suggestions you would like to make to help increase AUR awareness and understanding will be most welcome.

Currently we have official packages optimized for the i686 and x86-64 architectures. We complement our official package repositories with a community-operated package repository (AUR) that grows in size and quality each and every day. The AUR is the official community supported repository. It allows any program that is not officially supported by Arch to be introduced to the community through PKBUILDs written by the community. Please read the wiki for information on how to Build/install packages in the AUR.

maybe something along those lines... A "community-operated package repository" doesn't really say to much of what the AUR is capable of doing. Its not really a repository, like the binary extra/community/core repository is. This is what confused me so much when I first found the AUR. I just figured it was like all the other repositories, just d/l the binary and done, what I missed and what wasn't so clear was a way to tell me that it was different, slightly, and it provided a way to build the binary packages I needed to install later by hand.

I am not really sure how to go about telling you to fix the problem, but I think its just a matter of Arch not getting the point across about how and why Arch developed the AUR and how it can be useful to the Archers system.

The AUR is one of Arches strongest suits, next to KISS methodology, and makepkg/PKGBUILD is the base of how Arch dev's make extra/community/core repositories. So why not expand on this and show new potential Archers how KISS Arch really is while still having the functionality to install "ANY PROGRAM" on the internet trough a centralized package manager. Arch is not just a repository, it can be so much more... That is the IDEA that u need drive into the head of new potential archers IMHO. This is also what has separated arch for me from any other distribution.

Last edited by jacko (2008-01-31 19:41:43)

sen · 2008-01-31 20:48:06

zodmaner wrote:

Yes, yaourt make it easier to use AUR, but it is not necessary to use it.

That's exactly my point... yaourt make it easier and more comfortable to use AUR. If you want more users to work with AUR what better way is there to make this as easy as possible? In my experience the normal user is lazy, he normally won't prepare a complex meal by himself but put the food in his mouth and he will gladly eat it. I hope you get what I mean, it's probably not the best solution but you would reach the goal that way.

zodmaner wrote:

Also, there's a legal implication as well. Some packages in AUR have a license that prevent it to be included into the official repositories (that's why such packages are in AUR to begin with). So to include a function that allows automatic installation of such packages could be problematic.

You are absolutely right that making licensed packages available with a tool in the official repo would be a problem. I missed that point and totally agree that such a tool shouldn't be made available officially. A solution to that problem would be to flag those packages and modify a tool like yaourt to exclude those flagged packages.

It would be nice if such a feature would be included in pacman (licensed packages excluded, unsupported packages can only be installed when the user was properly notified and had a look at the PKGBUILD). This feature can be disabled by default and is only available via an option in the pacman.conf. In my opinion this would increase the usability of AUR because you can reach all repos (including AUR) with one tool, pacman. Don't flame me for that since this is just an idea and I don't know what problems this could cause.

An idea to the outdated packages problem:
The way it is now, one person is responsible for the maintenance of a package. So when this person runs out of time / has rl issues or whatever, the package won't be probably maintained. There is already the opportunity to write a comment or an email to notify the author about it(and at least people use the comment feature to notify about outdated packages). This won't help though if the maintainer simply isn't available anymore and to find someone who take over the package takes time.

My idea is to include a feature that allows the community to post up to date PKGBUILDs via a pastebin function that are separate from the maintained PKGBUILD. This way everyone who has the knowledge to do so can easily post his modified package without being the maintainer. Normally when I want to install an outdated package from AUR I update it myself but I never post it in the comments because I think this would be rude and piss of the actual maintainer... but such a feature would actually even make it easier for the maintainer!

here an example:

I don't know if the community would actually use this feature but I certainly would since I'm updating PKGBUILDs regularly anyway.

Don't get me wrong, I like AUR the way it is now and don't even mind if it stays as it is. This are just some ideas to improve AUR.

peart · 2008-01-31 21:26:11

sen wrote:

It would be nice if such a feature would be included in pacman ...

I don't think this is possible. There are other distributions like Frugalware that use Pacman, so it can't contain Arch specific things like AUR support.

shining · 2008-01-31 21:32:35

peart wrote:

sen wrote:
It would be nice if such a feature would be included in pacman ...
I don't think this is possible. There are other distributions like Frugalware that use Pacman, so it can't contain Arch specific things like AUR support.

That's the first main reason. The second one is that AUR is not controlled, anyone can post anything there.

shining · 2008-01-31 21:45:45

sen wrote:

An idea to the outdated packages problem:
The way it is now, one person is responsible for the maintenance of a package. So when this person runs out of time / has rl issues or whatever, the package won't be probably maintained. There is already the opportunity to write a comment or an email to notify the author about it(and at least people use the comment feature to notify about outdated packages). This won't help though if the maintainer simply isn't available anymore and to find someone who take over the package takes time.
My idea is to include a feature that allows the community to post up to date PKGBUILDs via a pastebin function that are separate from the maintained PKGBUILD. This way everyone who has the knowledge to do so can easily post his modified package without being the maintainer. Normally when I want to install an outdated package from AUR I update it myself but I never post it in the comments because I think this would be rude and piss of the actual maintainer... but such a feature would actually even make it easier for the maintainer!

Indeed, that's a bit problematic in some situations. But a possible procedure, which should work most of the time, is :
1) Send your updated PKGBUILD to the current maintainer by mail. Maybe also ask him kindly to orphan the package if he doesn't have the time to maintain it anymore
2) After a week (or more), if you didn't receive any answers, send a mail to aur-general ML so that a TU can orphan it for you.
3) Adopt it, update it. And when you also stop having the time to maintain it, orphan it.

In my opinion, it's better to proceed that way. But you can also achieve exactly the same thing you are suggesting without an additonal feature. Just paste the pastebin links in the comments. A simple url won't clutter the comments like a full PKGBUILD do. But how long does something on pastebin last? And also, it gets more problematic when there are several files (scriptlet, patch, scripts, whatever).

sen · 2008-01-31 22:10:58

peart wrote:

sen wrote:
It would be nice if such a feature would be included in pacman ...
I don't think this is possible. There are other distributions like Frugalware that use Pacman, so it can't contain Arch specific things like AUR support.

Well, it's just a feature which can be disabled by default as I suggested. Pacman would behave like before so, why would it cause a problem?

shining wrote:

AUR is not controlled, anyone can post anything there.

Yeah but packages that are not verified by a TU are flagged unsupported. So if you warn the User (a small disclaimer like - This package is not officially verified and may contain harmful code. Continue at your own risk!) and have him look at the package build, it should be fine (legally) right?

shining wrote:

Indeed, that's a bit problematic in some situations. But a possible procedure, which should work most of the time, is :
1) Send your updated PKGBUILD to the current maintainer by mail. Maybe also ask him kindly to orphan the package if he doesn't have the time to maintain it anymore
2) After a week (or more), if you didn't receive any answers, send a mail to aur-general ML so that a TU can orphan it for you.
3) Adopt it, update it. And when you also stop having the time to maintain it, orphan it.
In my opinion, it's better to proceed that way. But you can also achieve exactly the same thing you are suggesting without an additonal feature. Just paste the pastebin links in the comments. A simple url won't clutter the comments like a full PKGBUILD do. But how long does something on pastebin last? And also, it gets more problematic when there are several files (scriptlet, patch, scripts, whatever).

I agree that this way is cleaner but it also takes more time. If you already updated the package its faster to just post it so that the community can directly use it instead of waiting for days until the maintainer looks into it. It's not the normal procedure anyway because most maintainers do a really good job in my experience! It's just for packages where the maintainer clearly missed a few updates or where he isn't even available anymore. This way the community itself can interact more and easily share up to date PKGBUILDs without much effort.

If it's ok to post links to packages in the comments I'll do so. I refrain from it until now because I thought it would be to much spamm or even angry the maintainer.

shining · 2008-01-31 22:29:37

sen wrote:

I agree that this way is cleaner but it also takes more time. If you already updated the package its faster to just post it so that the community can directly use it instead of waiting for days until the maintainer looks into it. It's not the normal procedure anyway because most maintainers do a really good job in my experience! It's just for packages where the maintainer clearly missed a few updates or where he isn't even available anymore. This way the community itself can interact more and easily share up to date PKGBUILDs without much effort.

Indeed, this doesn't happen too often. That's why it's not a big deal that the cleaner way takes more time.

If it's ok to post links to packages in the comments I'll do so. I refrain from it until now because I thought it would be to much spamm or even angry the maintainer.

At least, I think it's better than pasting the whole PKGBUILD in the comments (which I have seen several times).
Besides, I just checked pastebin.archlinux.org, and it's possible to ask for the paste to stay forever

Zer0 · 2008-02-01 02:59:57

byte wrote:

Zer0:
About safe-flagging -> http://projects.archlinux.org/git/?p=au … 3b5015bc6a

Well I guess that answers that question.. thanks for the heads up!

Stoffi · 2008-02-01 03:41:18

I am new to arch, and my linux experience is beginning with arch.
and I found AUR too hard before I found yaourt.
the pkgbuilds aren't too self explaning to somebody who doesn't even know where to put the packages.
I have a thread in the AUR Package Requests part of this forum which recently came to a standstill.
I do try to read the guidelines, but sometimes, it is just too much at once, insuficcient, or not even there. (man pages etc.)

so, for somebody that can't even use the aur without yaourt or similar, the packagecount may be low.
allthogh, I can't say I have been missing something, if it is not someting unusual...

Misery · 2008-04-10 19:36:07

wuischke wrote:

My short list:
mingw32-wxMSW

By the way.... I added it to AUR. ;-) Happy Cross-Compiling!

Arch Linux

#51 2008-01-31 06:24:03

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#52 2008-01-31 08:22:38

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#53 2008-01-31 10:30:43

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#54 2008-01-31 16:20:10

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#55 2008-01-31 17:12:20

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#56 2008-01-31 18:04:04

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#57 2008-01-31 19:25:46

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#58 2008-01-31 20:48:06

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#59 2008-01-31 21:26:11

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#60 2008-01-31 21:32:35

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#61 2008-01-31 21:45:45

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#62 2008-01-31 22:10:58

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#63 2008-01-31 22:29:37

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#64 2008-02-01 02:59:57

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#65 2008-02-01 03:41:18

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

#66 2008-04-10 19:36:07

Re: "there aren't nearly as many packages in the repos/AUR as X distro"

Board footer