[aur-general] TU appliance Jens Maucher (defcon)

[Ali H. Caliskan]

Allan, you're right about your views, but unfortunately, zattoo seems to be
installed that way, so much for several contributors effort in this
inconsistency. However, I'll reconsider your critical approach when chaning
zattoo PKGBUILD.

One thing, mkdir is not something bad to use, I use it all the time, and
install isn't also not required, since the developers of install command
argue that a package manager should be used instead of install, so what's
the big deal here? I mean as long as the code is working, why should it be
that much trouble to maintain a package. Are we code "fascists" here?

/ali

On Sun, Apr 5, 2009 at 3:25 PM, Allan McRae <allan at archlinux.org> wrote:

> Ali H. Caliskan wrote:
>
>> I don't think zatoo should be that much criticized, it looks somewhat
>> clean.
>>
>>
>
> I am going to be fairly blunt here, but essentially you are wrong....
>
> e.g.
>
>  # Kerberos libs
>  ln -s /usr/lib/libcrypto.so libk5crypto.so.3
>  ln -s /usr/lib/libkrb5.so libkrb5.so.3
>  ln -s /usr/lib/libkrb5.so libkrb5support.so.0
>  ln -s /usr/lib/libgssapi.so libgssapi_krb5.so.2
>
>
> Symlinking libraries to different sonames is, in my opinion, the single
> worst thing you can do to your install.  It can create bugs that are
> incredibly difficult to track down.   The current libkrb5.so is .25!  A lot
> has changed since .3...  The correct way to deal with this is to find a
> version of the package that supplies these library versions and build it,
> either within the package or as a dep for the package.  The former is
> probably cleaner in this case unless something else requires these versions.
>
> There is also the use of "mkdir" and "cp" instead of "install" to improve.
>
> As Jens pointed out, he no longer maintains this.  But at this point, that
> is moot.  He maintained it when he applied and the TUs did not know him very
> well in general so we needed to rely on his packaging skill to judge his
> application.  The consensus opinion of the TUs was obviously that his
> package standards were not high enough and I have no doubt that this package
> was primarily to blame.
>
> So, for future reference, here is my subjectiveview of what should have
> happened after this package was pointed out as bad:
> 1) a reply to aur-general saying "I will look into it".  If it was fixable,
> good.  If not then...
> 2) a reply saying, "This is very difficult to fix.  I am discussing this
> with my sponsor.  Any suggestions on how to improve it?".
> 3) possibly delaying of voting until it is shown that the issue is fixed.
>
> I see the ability to know when you have a bad PKGBUILD or other problem and
> then asking for help to be far more important than the ability to produce
> perfect packages.  Remember, once someone is a TU, they will be providing
> the community with binary packages.  It is essential that the Trusted Users
> ensure any new applicant is up to standard.  Any doubt is enough to say no.
>
> Allan
>
>
>
>