You are not logged in.
Pages: 1
Topic closed
I may be wrong but it seems there is no aur support in pacman because aur packages should not be assumed safe. This could be fixed by adding an option to view and edit the PKGBUILD etc before building and/or installing as is done in yaourt. I think adding a warning and commenting out the aur line in the default pacman.conf would be enough warning for arch users to use aur with care. I see no need to add inconvenience.
Right now most users resort to hacks such yaourt. Also makepkg -s depenency handling does not support aur.
I don't know how hard it would be to add support for aur in pacman but I think it should be added to the roadmap.
Offline
NFW ;P
What's wrong with AUR helpers? I wouldn't call e.g. bauerbill 'a hack'.
Offline
yeah clyde is also awesome.. just as functional if not moreso than pacman.
[home page] -- [code / configs]
"Once you go Arch, you must remain there for life or else Allan will track you down and break you." -- Bregol
Offline
AUR packages should be assumed safe? There's no one policing the AUR except a relatively few astute users. I've seen more than one package that drops executables in the user's home folder, which is totally insane.
Last edited by skottish (2010-09-19 01:43:52)
Offline
AUR packages should be assumed safe? There's no one policing the AUR except a relatively few astute users. I've seen more than one package that drops executables in the user's home folder, which is totally insane.
From the bauerbill manpage:
--blindly-trust-everything-when-building-packages-despite-the-inherent-danger
This option enables pacman's "--noconfirm" option to bypass the PKGBUILD and install file inspection
prompt for all packages. This option is VERY DANGEROUS and IT IS NOT RECOMMENDED THAT YOU USE THIS.
The only reason that this is included is because some users desperately want this functionality.
The author highly recommends using the options to trust ABS packages and specific AUR users instead of
this option, which can be used to achieve essentially the same effect.
Offline
AUR packages should be assumed safe? There's no one policing the AUR except a relatively few astute users. I've seen more than one package that drops executables in the user's home folder, which is totally insane.
aur packages should NOT be assumed safe.
Offline
skottish wrote:AUR packages should be assumed safe? There's no one policing the AUR except a relatively few astute users. I've seen more than one package that drops executables in the user's home folder, which is totally insane.
AndreasBWagner wrote:aur packages should NOT be assumed safe.
Are you implying that I should read all of the words in a sentence?
*** skottish crawls away ***
Sorry about that.
With all due apologies, all of the tools necessary are already in place; It just takes user diligence.
Last edited by skottish (2010-09-19 02:06:33)
Offline
I have personally seen a few nasty PKGBUILD and .install files, including a load of rm -rf /usr/share/stuff instead of rm -rf $pkgdir/usr/share/stuff and similar.
One .install file was so helpfull that it did a rm -rf /home/mpd when you uninstalled the package.....
Anyway, it's just as much about deniability as of the security of aur packages. As an example refer to the whole ion3 issue some years ago.
Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest
Offline
It just takes user diligence.
I wish I could buy you a lifetime supply of something you thoroughly enjoy.
Offline
It's too dangerous for users who don't understand the concept of AUR.
It is USER SUPPLIED CONTENT, with no form of quality control or review process. As opposed to official packages provided by distribution devs, and *trusted* users.
It would be improper to officially provided automated methods to install user content that could do anything to your system. Use of the 'makepkg' tool is official, but it's a totally different process to reinforce the distinction between the 2 types of 'packages'
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Finally, the AUR is Arch specific. pacman is not distribution specific. The pacman developers will not accept distribution specific features.
Offline
It's too dangerous for users who don't understand the concept of AUR.
You should not implement features because users could be too stupid to use them?
I don't think that goes well with the philosophy of Linux distributions like Archlinux...
฿ 18PRsqbZCrwPUrVnJe1BZvza7bwSDbpxZz
Offline
fukawi2 wrote:It's too dangerous for users who don't understand the concept of AUR.
You should not implement features because users could be too stupid to use them?
I don't think that goes well with the philosophy of Linux distributions like Archlinux...
Starting from next year Archlinux will be Ubuntu based.
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
I'm not sure what the issue is here.
pacman -Ql pacman | grep makepkg
pacma /usr/bin/makepkg
Pacman has full support for AUR packages, right now and as is. Users who are too stupid to use makepkg have no business installing anything from the AUR .
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Finally, the AUR is Arch specific. pacman is not distribution specific. The pacman developers will not accept distribution specific features.
Just repeating, THIS is the reason pacman does not support the AUR.
The reason AUR helpers do not get added to [community] is that AUR is completely unsupported content.
Those are two different things.
Offline
fukawi2 wrote:It's too dangerous for users who don't understand the concept of AUR.
You should not implement features because users could be too stupid to use them?
Same reason rm has the --no-preserve-root option
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
My biggest problem with this is insufficient integration between makepkg+pacman+etc with aur, for example "makepkg -s" will not get dependencies from AUR.
* AUR needs to look like another repository such as community (with the exception of no sources or binaries included).
* Pacman and similar need to make it possible to check out the PKGBUILDs before installing them for regular repositories not just AUR, because anyone can set up a repository.
I am considering coding and setting up an AUR-to-Unofficial_User_Repository interface on google appspot for the purpose of using AUR with pacman & "makepkg -s" but I still could not edit/inspect buildscripts before using them.
Offline
My biggest problem with this is insufficient integration between makepkg+pacman+etc with aur, for example "makepkg -s" will not get dependencies from AUR.
* AUR needs to look like another repository such as community (with the exception of no sources or binaries included).
* Pacman and similar need to make it possible to check out the PKGBUILDs before installing them for regular repositories not just AUR, because anyone can set up a repository.I am considering coding and setting up an AUR-to-Unofficial_User_Repository interface on google appspot for the purpose of using AUR with pacman & "makepkg -s" but I still could not edit/inspect buildscripts before using them.
Or you could just bauerbill, or clyde, or yaourt, or any one of the others that fully automate this process.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Or you could just bauerbill, or clyde, or yaourt, or any one of the others that fully automate this process.
^ This.
Closing this thread to avoid further repetition.
ᶘ ᵒᴥᵒᶅ
Offline
Pages: 1
Topic closed