On 02/03/12 23:16, Heiko Baums wrote: > Am Fri, 02 Mar 2012 22:01:59 +1000 > schrieb Allan McRae <al...@archlinux.org>: > >> I see what was done there... makedepends in split packages probably >> need to become depends when built as individual packages. >> >> @György: Let that be a lesson in being careful when making >> reactionary changes to packages. Don't worry... it is a surprisingly >> common occurrence when people first become a TU and start getting bug >> reports. There are always annoying and persistent users that think >> they are right, > > If I'm so annoying and I'm so wrong then explain why his packages are > so good and I'm so wrong, but this time try it with facts.
Fact. I never said you were annoying or wrong in that sentence. Someone is a bit sensitive... probably because he is annoying and wrong. > Explain to me e.g. - I know I already asked that Stéphane - why it is > such a good packaging quality to have two totally different depends > arrays in one PKGBUILD of which one is also prefixed with a "true &&". That fixed the issues you were complaining about with AUR helpers unable to find dependencies. So hang on... this was a complete solution to having a split package in the AUR while still being able to use an AUR helper. So what was your problem again? Apart from ignorance... > Where in the Arch Packaging Standards is this written down? In which > PKGBUILD proto can this be found. Where is it written that you can't do that? PKGBUILDs are bash. Any valid bash is a valid PKGBUILD. Show me an PKGBUILD proto that shows specifying different dependencies for i686 and x86_64? Given there is none, should all packages doing this be removed? Note that also screws AUR helpers. > Since when it is a good packaging quality to upload packages which > can't be installed? They can be installed. Or do you mean can not be installed by an AUR helper? In which case you are still wrong due to the extra dependency line. > Just explain it factually to me. And don't tell me anything about "not > officially supported". Neither the helpers nor the split packages are > "officially supported". This is not an argument in this case. It is a valid PKGBUILD that provided split packages with a modified dependency line to fix AUR helper issues. >> so you are better of not making reactionary changes >> to packages. It is important to learn when a change does not need >> implemented, and this change was probably not needed when no TU had >> posted about having issues with the split packages. > > This change was neither reactionary nor unneeded, just because it was > not possible to install this package. So this change was needed. So > don't mix up the facts. Absolute shit... the package installed just fine. > In the repos like [community] split packages are supported and are no > problem. And in the repos there's no need for such dirty workarounds. In > AUR it is totally different. And that is just a fact, even if you don't > want to hear that. I agree that in the AUR it is totally different to the repos. You have to use workarounds in the AUR. So everything said in that paragraph is true. Allan