[clc-devel] Ports reorganisation?

Johannes Winkelmann jw at tks6.net
Wed Jan 14 09:07:54 UTC 2004


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.
Yeah, that's fine with me

> 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
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 at tks6.net
Bern, Switzerland                http://jw.tks6.net



More information about the crux-devel mailing list