[aur-general] TU Application - György Balló
allan at archlinux.org
Fri Mar 2 09:49:56 EST 2012
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 at 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
More information about the aur-general