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 <allan@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