On Sat 03 Mar 2012 01:15 +0100, Heiko Baums wrote:
Am Fri, 2 Mar 2012 17:16:16 -0500 schrieb Loui Chang <louipc.ist@gmail.com>:
First of all I'll deplore you for hijacking György's TU Application thread to rant about your own qualms. You should be ashamed. You should apologise. You are wrong.
I'm not wrong, I didn't hijack anything, and I didn't rant. I gave my concerns about György's TU application and explained them. Afterwards I just answered some not so nice reactions and kept giving my arguments. So nothing to be ashamed, nothing to apologise. And, no, I'm not wrong. Just because you say so?
Yes. Because I say so. Because everyone else says so. Because you are one of those imbeciles that don't stop to listen and simply talk over everyone so that you can only hear yourself shouting.
Like I already said, give some factual and reasonable arguments. You, too, didn't give even one.
Secondly. If a PKGBUILD can be built with makepkg then it IS a valid PKGBUILD. No matter what you say. If an AUR helper cannot process it, then there is a problem with the AUR helper, not the AUR and not the PKGBUILD.
Also wrong. If a PKGBUILD has no syntax errors does not mean that it is valid resp. good. See my example of the package with the `rm -Rf /` in its post_install(). This package is totally valid, because it's totally valid bash without any syntax errors. This package can perfectly uploaded to AUR, is fully supported by AUR and every AUR helper, and can flawlessly be installed. Is it a good package, just because it is valid and has no syntax errors? Just think about that and think about the meaning of quality, quality assurance (QA) and good packaging.
Obviously you don't know the meaning of the word 'valid'. For instance: I could write a program in C with gotos. It could be perfectly valid, since goto is a valid instruction, but it might not be pretty, or good practice, or recommended. If I put a 'rm -Rf /' command in a script I damned well meant to put it there. It's a valid command. The script does not magically become invalid because you don't like what it's doing. If it runs, it's valid. (permissions errors aside)
The AUR helpers - all of them - support everything what AUR supports. AUR does NOT support split packages. Otherwise such a hackish workaround wouldn't be needed. So there's no problem with the AUR helpers. Would this be a problem with an AUR helper I would have filed a bug report for this.
Third. The AUR is not meant to help you build source packages. It hosts them, and parses the tarballs only for convenience. You are supposed to install it by your own means. If your means are buggy, that's your problem.
Wrong again. AUR is meant to provide PKGBUILDs so that other people can use and install them without rewriting them by themselves. They don't parse them only for my convenience, they parse the PKGBUILDs to assure that the PKGBUILDs are valid and most likely working.
Lemme see... Do you have any experience writing or otherwise hacking on an AUR helper, or for that matter the AUR itself? Otherwise how on earth are you able to declare the intents of its developers? Anyways, no the AUR was not meant to do your work for you - at least while it was on my watch.
Finally, yes, there are problems with Arch source packages but you're missing the solution by lightyears. These things have been discussed on the list, the forums, and the bugtracker. You would be keen to do a little research and perhaps propose solutions (patches?) rather than wasting precious oxygen.
I know these discussions, and I know the results of these discussions. You seem to have forgotten them. And, yes, the result of the discussion about implementing support for split packages into AUR, which was requested by a lot of people, btw., was that it does not going to be supported, because nobody wanted to write the patches. Maybe you have missed this discussion.
The issue has been hinted at by Xyne in the previous thread. Your problem is that your skull is too thick for that notion to seep deep enough to reach that pistachio nut you call a brain. Thanks for playing.