[clc-devel] httpup repositories and unmaintained (next try) [long]

Johannes Winkelmann jw at tks6.net
Fri Aug 20 17:59:44 UTC 2004


Hi there,

I have yet another proposal about a change I'd like to make, addressing
the problems I see with the current httpup repositories and
unmaintained. I think this one is good; at least better than the
situation as it is now.


First of all, the following are the problems I'd like to address:
- distributed port repositories suffer from the following flaws:
  1. it's confusing at least to subscribe to ports; especially for new
     users
  2. People put just everything into they're repositories, e.g. duplicates
     over contrib ports, but also duplicates when using multiple private
     collections. This has two bad consequences: there is no improved
     version by merging the ports, and it is important to choose the
     right order in prt-get.conf

- ports in unmaintained are outdated; often, there are newer variant
  in private httpup repositories

When looking closely at unmaintained, there are two kinds of ports
there: first those of us CLC maintainers which we don't think are quite
ready yet; second such from external guys, often submitted with the
submission service we had a long time ago, and maybe updated by an
update report.


What I'd like to suggest differs a bit from my httpup mirror service
proposal I wrote to crux@ a while ago and is rather what Jay Dolan
suggested: Create a new httpup collection, called 'people' (for example;
I have no strong opinion about the name of this thing); packager can
apply to have their repository included in this collection. There are a
few basic rules to follow:
- No dups over base, opt or contrib; use a separate repository for this
- Rather have few but well maintained ports, than many outdated ones
- React on conflicts
- subscribe to and read the clc-people-admin (naming comment from above
  applies again) mailing list

If a conflict (duplicate) is detected, a notification is sent to a
clc-people-admin; the packagers are required to resolve it.
-> there must be an instance to decide if the packagers can't agree on a
  compromise

If a repository goes offline, the port remains in the collection, but is
marked as unmaintained. This way, a new packager can pick it up by
simply adding the port to his/her collection. This is exactly the same
sitation we have now, except for the fact that once a new package
appears, the new version will be used.
We can still use an external tool to check which ports have been
unmaintained for a long time and remove them.


The other purpose of the current 'unmaintained' collection, the ports
from CLC maintainers which are not ready for contrib, should be moved
into private port repositories. Many of us have them anyway.


This solution has the following properties (with respect to the current
sitution):
- people can easily pick up ports from unmaintained and provide new
  versions through the 'people' collection
- httpup repositories are available at a central location
- all ports are in the ports tree -> use find/grep/prt-get to search
  them; disadvantage: large number of ports (probably)
- httpup repo maintainer have a meeting point with others in the same
  position, which might help to improve ports

Most important, this would change the meaning of unmaintained:
'unmaintained' would mean that there's no CLC maintainer and no httpup
maintainer looking after the port.


I have a script ready to do most of the required work to collect the
repositories, find dups, merge the ports, mark them 'unmaintained' if a
repository fades away etc. It can definitely be optimized, but it is
ready for a test run.


For those still reading, what do you think? is this a viable solution?
I'll happy write a more detailed description and drafts of requirements,
but I'd like to avoid it if there are objections.

Feedback is (guess what ;-)) highly appreciated.

Thanks for bearing with me && kind regards, 
Johannes
-- 
Johannes Winkelmann              mailto:jw at tks6.net
Bern, Switzerland                http://jw.tks6.net



More information about the crux-devel mailing list