[aur-general] TU Application - György Balló
allan at archlinux.org
Fri Mar 2 08:40:55 EST 2012
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
> 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