On 02/03/12 23:40, Allan McRae wrote: > 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...
I'll put my hand up and say I am partially wrong here. This broke AUR helpers that blindly source the PKGBUILD in order to get the dependency list. I.e. broken AUR helpers became further broken... The AUR helper I use worked because it very sensibly does not do that and ends up with the same (working) dependency list as was displayed on the AUR. In conclusion... a good hack that did not work in shitty AUR helpers. >> 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 > > >