![](https://secure.gravatar.com/avatar/73a8f5105a881a41b5fe876b1ca926fc.jpg?s=120&d=mm&r=g)
Hi Martin, On Wed, Jan 14, 2004 at 09:08:52 +0100, Martin Opel wrote:
I'm sorry for the late reply, too. I have the following suggestions:
1. unmaintained: we remove it from cvs and copy the plain files to a http-repository. from then on it is distributed by httpup. Without the pros and cons of cvs.
2. We write a php upload page on crux.fh-regensburg.de, where users can upload new ports (as gzipped tarfiles). The files run through a few sanity checks and go directly to the direcory from point 1. How about creating this repository from other httpup repositories? Uploading 10+ ports via web frontend is rather inconvenient IMO. Merging
Yeah, that's fine with me the distributed httpup's automatically would make it much cooler :-) This would usually mean: for a port from unmaintained, copy it to your upload directory; do some updates; upload to server -> synced automatically I'd suggest a discussion on GnuPG signing of REPO files to have some information about the packager (most notable: e-mail address), and introduce an additional md5sum check: right now, files fetched from the web are not checked against the REPO md5sum. I could introduce a --pedantic-md5 flag to httpup. Of course, the problem of duplicates needs some rules. IMO packagers should discuss how to merge their ports (of they're not equal) and discuss their differences to get a common solution. I'm not quite sure though what to do if they fail to find a consensus: 1. Discuss and decide in CLC? + probably best for the integrity - maybe a lot of (uninteresting) work - one packages gets turned down, maybe for very small reasons; doesn't improve his opinion of CLC 2. Have multiple ports (mplayer, mplayer-gui) + all kind of wishes are covered - updates are duplicate work - "packaging competition"; don't think that's a good thing In the end I think it's not a bad approach to have duplicates and discuss them in a dedicated mailing list, as you can learn a lot from other packagers. Of course, the httpup approach has some problem as well; packager can disappear, but they're httpup repos are still online. In such cases, we'd need to stop updating from his repo to allow others to maintain his ports... we could require all maintainer to visit an URL with id every month to make sure they're alive. Comments here? Regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net