[aur-general] TU Application - György Balló

[Allan McRae]

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
> true.
> 
> Allan
> 
> 
>