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

[Allan McRae]

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

> 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