![](https://secure.gravatar.com/avatar/4e374bb9f03cbbca5d9541a8bf8ec8bf.jpg?s=120&d=mm&r=g)
Hi Lucas, On Wed, Oct 08, 2008 at 21:23:32 +1100, Lucas Hazel wrote:
So it appears I've been handed the "portdb maintainer" hat.
My first duty in this roll was to add a few repos to the portdb cacher. But alas the pdbcacher seems to have locked up and I don't have the privileges to kill the process.
So rather than find out what's wrong with it, I've decided to write a new one (sans PHP) with a focus on me having to do as little data entry as possible.
Nice
A few features I have in mind are,
* Allow users to add repositories by themselves.
* Allow users to create custom collections from other repositories. Not sure if that should be part of crux.nu's portdb. I can see that users create meta repositories, but I'm not sure if we should host them. Or is this mean to be a private custom collection, or just a special
Cool; if we have proper user management, that could also be used for a number of other things. It would be nice if users wouldn't need three accounts for crux.nu (wiki, flyspray, portdb); not sure which application could/should be the "master" though. ports configuration file for a yet-to-be written ports(8) driver that can merge repositories?
* Partial and full caching of repositories. Does this mean that one can browse the files on crux.nu? I'd really like to see that again, as right now (at least for rsync) you can't e.g. check versions and the like.
* Make more information available, such as processing footprints, md5sums, meta data and verification results. Sounds good. It would also be nice if users could flag packages outdated, which would trigger a bug report to portdb, similar to what the Arch guys have.
Maybe portdb could also show if there's already an outdated (and maybe also other bugs?) reported.
* XML output, RSS feeds, email alerts, etc. * ??? * Profit
Does anyone else have any nifty ideas for what could go into a new portdb? Well, one thing I'd like to animate is that repo maintainers must confirm on a regular basis that they're looking after their repositories; I would suggest that we send a mail with a generated URL, which confirms that a repository is active when visited. If a maintainer fails to confirm (maybe only the second time), his repositories are deactivated (hidden) from portdb. He can always log in later on to reactivate them.
Thanks for working on that! Cheers, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch