[clc-devel] httpup repositories and unmaintained (next try) [long]
![](https://secure.gravatar.com/avatar/73a8f5105a881a41b5fe876b1ca926fc.jpg?s=120&d=mm&r=g)
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@tks6.net Bern, Switzerland http://jw.tks6.net
![](https://secure.gravatar.com/avatar/f355c0bbce9ca262c393caba55503522.jpg?s=120&d=mm&r=g)
Johannes Winkelmann wrote:
Hi there,
Well, I wanted to write so as to not look as though I wasn't participating at all, but I have mixed feelings about this. It seems to me the "right" way of doing this is to do web service type architecture, where people just log in, upload their ports, and then the system can sort them out and send them to clients that connect via curl and request data. However since this system would require some development and effort, and noone (including myself) can/want allocate time to it, this sounds ok to me, I am just not sure this would scale or solve/automate the current issues. Victor
participants (2)
-
Johannes Winkelmann
-
Victor