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

[Aaron Griffin]

On Tue, Oct 6, 2009 at 2:19 AM, Allan McRae <allan at archlinux.org> wrote:
> Aaron Griffin wrote:
>>
>> Arch Linux Status Report, 2009-10-05
>> ===================================
>> Aaron Griffin
>>
>> Yes, a new status report. I haven't put one of these out in some time, and
>> a lot
>> has happened since the last one, so bear with me here.
>>
>
> Woo!  Good to see one of these again.
>
>
>> <snip>
>> * Replacing cron with fcron
>>
>> This was brought up on the ML a bit ago. It appears that most of us are in
>> favor
>> of using fcron to replace our existing dcron. I would like someone to
>> spearhead
>> this move. Any volunteers?
>>
>
> I'm starting to lean towards vixie-cron as fcron still does not support
> /etc/cron.d.   Why are we switching otherwise?  Are there other issues with
> dcron?

Well, dcron seems to have a handful of minor issues and it's really
just kind of... blah. Most of the time we try to walk the line between
"vanilla" and "modern". dcron just feels.... old. And, based on the
bug reports, it seems most other devs like fcron.

I mailed the fcron maintainer and he DOES still maintain it, but
considers it feature complete, so does no active development.

Regarding cron.d, it can be emulated with a script that merges cron.d
files into a system crontab. We could potentially include this in the
rc.d script.
http://fcron.free.fr/doc/en/faq.html#AEN2949

>
>> * Ensuring Package Quality
>>
>> 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