Generic ATI package in the AUR:
http://aur.archlinux.org/packages.php?d … =1&ID=2566
Should build against any kernel, just follow the instructions. No more dependancy hell
Unfortunately I have to delete this pkg as it a) is against the AUR rules b) is pointless (why not remove the dep line from teh standrad PKGBUILD) and c) is really annoying for me personally (devalues work for which I already receive no credit or support)
Thanks for bringing the acces_ok.patch and new release to my attention.
If you are not happy with the current situation with the ATI drivers then you will need to do something other than create a redundant PKGBUILD - it would be better if we could work together rather than replicate effort.
I'd just like to clarify that the ati-drivers are built against the archck drivers for tradiational reasons. If there is greater demand for support for the stock kernel then I would build against that. But this is not just a PKGBUILD - we cannot supply a binary that will suit everyone. For reasons of transparency the binary MUST be built against a specific kernel tree and ideal that kernel tree should then be used as dependecy. This increases reliability and prevents "mysterious" errors when a module built against one kernel won't work with another.
ABS exists so that any Arch user can take a pkg and convert the PKGBUILD to their own use, on their own system. All [community] build files are available via ABS and so the ati-drivers can be easily built against any kernel you like.
Please try to understand the situation within which we ALL must work.
Your right. I don't like it, but your right and I respect your decision.
Glad to be able to contribute the patch.
Still I wish there was a better way...
Well, a binary can only be built against one kernel tree and it is Arch policy to only supply one binary, but we do have ABS to account for the other cases. That's the best I can do I am afraid.
If ati-drivers get moved to extra they WILL be built against stock - that's a matter of certainty.
I understand and totally agree.
And I just want to say a big thank you to you for all the hard work you've put in maintaining the package.
I look forward to the package eventually making it into extra.
Not to be an ass, but lets say an Arch user doesn't use the 'standard' arch kernel. Want's to venture off on his own but still wants to maintain a proper package, we now have to wait for your PKGBUILD in 'abs' to suit our needs? That seems a little off.
You don't appear to understand the system - you can do what you like, you just can't put a PKGBUILD in the AUR for it. Strictly speaking you shouldn't post it on the forums either as all PKGBUILDs are supposed to go in the AUR now
Basically anthing can be accomplished by a competant user with ABS. The more PKGBUILDs people have access to, the less they ned to use ABS, which I think is a bad thing.
c14n: Don't feel bad, I had the same reaction when dibble first pulled my package. But then I realized how crazy it would be if everyone put their version of a package in the AUR.
The "Arch Way" is to have sane defaults that a competent user can customize given sufficient documentation and I think dibble's package meets that litmus test in this case.
Having had time to think about this, I think my only issue with the system is that if a user other than a package maintainer can update a package to a newer version and does, the Arch community still has to wait for the original maintainer to get around to updating their package. Not a big deal in most cases, again since there is the ABS addresses that, but a little annoying none the less. I think that's were mine and perhaps your uneasiness originates.
But then I realized how crazy it would be if everyone put their version of a package in the AUR.
I wish a lot more people would consider that scenario! I can't think of the number of times I have had to explain such a situation.
Are you talking about the binary in the last part? Updating the binary and how slow that can be sometimes? Yeah, that does suck but we are all only human The system does work at the moment, it still needs improving but it basically works. The only thing that can really help the situation is the growth of a competant user based, which is something I try in everyway to encourage. If everyone learned how to use ABS to its fullest we would have loads of quality pkg maintainers developing over time. The other thing is you get quite a high turn over with Linux users sometimes, they are only here for a short time, learn loads, offer to help and then "wham" they're gone when the next release of "Flatulent Stoat" hits the shelves
I would like to see the ati driver built against the standard kernel at this point in time. I believe the NVidia one isn't it? I think the vast majority of Arch users use the standard kernel (I know the ubergeeks will find that hard to believe ;-), and we would benefit from the package being available to us. Having said that, I am still able to get the installer from ati and it works quite well on its own. I just installed the new 8.18.8 driver against 2.6.13 and it worked just dandy.
I've got a lovely bunch of coconuts...