[arch-dev-public] Arch Linux Status Report, 2009-10-05

[Roman Kyrylych]

On Tue, Oct 6, 2009 at 18:02, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On Tue, Oct 6, 2009 at 2:19 AM, Allan McRae <allan at archlinux.org> wrote:
>> Aaron Griffin wrote:
>>> We run into package quality issues every so often. No, I'm not pointing
>>> fingers
>>> or anything, I'm guilty of this as well. I'd like to institute some way to
>>> ensure that our packages are of the proper quality before they hit the
>>> repos.
>>> Ideas are welcome. Currently, I had the following ideas in my head:
>>>
>>>   * Add some token to the PKGINFO indicating that makechrootpkg was used
>>>     This has the con of requiring this tool, when people may be using
>>> their own
>>>     chroots or tools for this.
>>>   * Make db-scripts check packages with namcap, and reject them on errors
>>>     This has the con of making the db-scripts slower.
>>>   * Combine the above: Add a PKGINFO token from namcap
>>>     We should all be running namcap anyway
>>>
>>
>> I'm really not sure we can force anything.  I do not build packages which
>> are just a repackaging of a script in a chroot (e.g. winetricks).  And
>> namcap still gives some false positives, especially when doing a soname
>> rebuild and then checking the package on your main system (as db-scripts
>> would...).
>
> Perhaps we can work on namcap to get rid of these false positives.
> Alternatively, installing something like namcap-reports might be a
> decent idea too:
> http://wiki.archlinux.org/index.php/Namcap_Reports

I think there always will be cases where namcap cannot be 100% sure.
For example when some binary in the package requires
some library but that binary is not important so the library is in optdepends,
instead of depends.
Or the case with hicolor-icon-theme.
So there should be a way to ignore namcap's results anyway.

That said I agree that improving packages quality is needed,
it's just that automated checks cannot be 100% trusted to take
decissions if the package should be accepted to the repo or not.

-- 
Roman Kyrylych (Роман Кирилич)