You are not logged in.
Lately I have been needed all types of utility and dependency packages, and community repo is often there to provide. AUR and community repo is great! My thanks to all AUR contributors and TUs.
Markku
Offline
Couldn't agree more. AUR is the single best idea I've come across in ages - it adds so much to the Arch experience, not only by providing a wide range of applications, but also by spreading the knowledge required for others to build even more applications. I've learnt so much from the AUR, and continue to do so.
Offline
Technically, I am quite dumb... but anyway, before AUR, Arch was just an exhellent distro. After AUR, it is the perfect distro... nuff said.
Microshaft delenda est
Offline
I must agree, AUR is a pretty genius idea. and theres nothing else like it out there.
iphitus
Offline
Best idea since sliced bread even
Offline
AUR - The Awesome User Repository. Official name change?
Offline
Does that mean we're all Awesome Users?
Offline
Still would like to have aur in pacman...
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
Still would like to have aur in pacman...
I agree.
I've moadned a couple of times about the lack of a decent interface to the AUR for 3rd party apps. I'd love to add an AUR feature into Jacman, but I can't be bothered to write all that hackish code to scrape html listings, etc. Whether that be read-only access to the AUR DB, XML-RPC or such-like, I don't mind.
Offline
Still would like to have aur in pacman...
I think this is the wrong approach. AUR unsupported is inherently unsafe. We do have TUs flagging packages as safe, but tools such as aurbuild (which I use extensively, don't get me wrong) are likely to open big security holes for users that don't check or don't know how to check the PKGBUILDs.
We already have AUR in pacman -- the [community] repository. Rather than having more inherent support for aurbuild-style building built into pacman or makepkg, it seems to me we need more unsupported packages going into [community]. This means we need more TUs.
I'd also like to see more [community] packages going into [extra], which means we need more developers. ;-) But officially supporting aurbuild-style tools in pacman is just not a safe idea.
Dusty
Offline
I agree with Dusty. Pacman shouldn't be supporting packages in "unsupported".
That being said, if you want to see more stuff moved to community, then vote on aur.archlinux.org! I truly think a lot more than the 10 or so people who vote for packages are using those packages. If you use a package, and think it was installed correctly, vote for it.
Offline
Pacman shouldn't be supporting packages in "unsupported".
Red mage agrees with black mage. There're some new TU's coming in soon, and they'll be looking for packages to adopt - make sure you get out there and vote for your favourites!
Offline
I agree with Dusty.
It is very good that we have 3 new TUs this month. But this is not enought. We still need more developers and TUs, as they cannot update all packages fast and at the same time work on improvements and adding new packages.
I'd like to see in the future Arch will have ~30 main developers and ~100 TUs.
to live is to die
Offline
I also agree with Dusty.
If you use a package, and think it was installed correctly, vote for it.
I would like to point out that voting isn't related to the package quality: it's related to whether you would like to have the package in the community repo. If there's problem with the package, post a comment in AUR but you should still vote for it if you want it to go in community. If the package gets enough votes, it will be noticed by a TU and and if he decide to adopt it, he will fix/improve the package before putting it in community.
Offline
Edit:
Offline
Pacman shouldn't be supporting packages in "unsupported".
... by default.
I fail to see why users that don't mind taking that risk should have to be "punished" because some users don't want it or wouldn't use it. Frankly, I would love to be able to review a PKGBUILD, make sure it's not going to hose my system, and then just pacman it. If you don't want that feature, then don't use it.
It's amazing how everything in linux always seems to be two steps forward, one step back. (The one step back coming from users who apparently know what's best for everyone else.)
As to the subject at hand, AUR is definitely a blessing, and I hope that more will come of the project in the future.
I am a gated community.
Offline
I fail to see why users that don't mind taking that risk should have to be "punished" because some users don't want it or wouldn't use it. Frankly, I would love to be able to review a PKGBUILD, make sure it's not going to hose my system, and then just pacman it. If you don't want that feature, then don't use it.
We have this in aurbuild... if it bothers you that much, you seem to have enough knowledge to write a script that will call either pacman or aurbuild for you. Name the script pacman and you're done.
Dusty
Offline
The one step back coming from users who apparently know what's best for everyone else.
I don't see how it's a group of users "knowing" what's best for everybody. It's pretty clear in my mind: AUR is broken into two categories, community and unsupported. Community is maintained by the TUs and is 'supported' by pacman. Unsupported is 'unsupported' by pacman by definition.
Aurbuild is available, it's a great tool, and it does what you're looking for except that it's not called 'pacman'. If you're capable of 'enabling' unsupported in pacman, you're capable of grabbing aurbuild and using that, IMO.
Offline
It's not that we are choosing what's right and whats wrong for you, it's that we are choosing which packages to support. You can dl aurbuild and do the rest yourself without much hassle.
Pacman only handles packages. Not PKGBUILDs. To include unsupported functionality in pacman would be to package anything someone puts up on aur.archlinux.org. And that would be retarded. We all know of one package we didn't get right the first time on the AUR, and the last thing I would want is to have someone download a package, and be screwed.
Putting unsupported packages in a repos for pacman ... is supporting them. That's not something anyone should be willing to take on.
Offline
News Flash:
Pacman installs binary packages, it is not capable of building them from PKGBUILDs.
Everything in unuspported is in PKGBUILD, not binary form, therefore pacman could not handle it.
The suggestion box only accepts patches.
Offline
I think what people would like is an official aurbuild-like tool.
AUR has been a great success. I don't think any one wants the PKGBUILDs in the AUR to be held as binaries in a repo somewhere. However, support for querying and installing from the AUR seems a logical request, in my mind.
Heck, I'd even like to be able to submit pkgbuilds via a cli rather than the web interface.
Offline
...support for querying and installing from the AUR seems a logical request, in my mind.
I agree with this 100%. qpkg will do this now, maybe some of its functionality could be build into pacman its self.
Also, my main use of qpkg is the ability to search the repos for the package that includes a particular file, via qpkg -f <file>. It is very similar to "apt-file search" in debian. I think that is an extraordinarily valuable tool, and it would be cool if it was included in pacman.
Offline
However, support for querying and installing from the AUR seems a logical request, in my mind.
You mean something like this?
aurbuild -S jedit
Name: jedit 4.2-5
Description: Java based extensible text editor
Location: unsupported/editors
Maintainer: Dusty
Votes: 19
Safe: Yes
It already supports querying. ;-)
Dusty
Offline
Heck, I'd even like to be able to submit pkgbuilds via a cli rather than the web interface.
I'd like that too, I must say, with batch submission as well.
I predict an AUR feature request in the near future.....
Offline
arooaroo wrote:Heck, I'd even like to be able to submit pkgbuilds via a cli rather than the web interface.
I'd like that too, I must say, with batch submission as well.
I predict an AUR feature request in the near future.....
Actually, IIRC, this was an original part of the design plan for AUR. Wonder what happened to it. We also wanted to have a sort of 'automatic' voting system based on Arch Stats that would count packages installed from community and unsupported and provide additional information about which packages are more popular.
Dusty
Offline