<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 3 Jun 2012, at 23:11, Tuncer Ayaz wrote:</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><blockquote type="cite"><blockquote type="cite">- We should consider leveraging existing ftp mirror networks like<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> distros and texlive do. For both the files and index.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">How will this work in practice?<br></blockquote><br>We'd have to figure out how the files can be distributed on existing<br>mirror networks. It wouldn't be the first open source project doing<br>that.<br><br></div></blockquote><div><br></div><div>Hi - sorry for not commenting about this sooner. I agree that it's a solvable problem, as long as someone 'sponsors' the storage somewhere, as well as dealing with the mirroring. Given some kind of mirror network backed by, say, FTP - how are you going to deal with authentication and authorisation? More specifically, when I decide that I want to publish my stuff, how're you proposing that the underlying source determines that I am (1) who I claim to be and (2) have the right to publish/upload this 'stuff'. I am fully aware that various solutions exist to this problem, I'm just wondering how you envisage this being handled in a way that minimises administrative overhead - consider that mine and Eric's initial suggestion about this removes this overhead altogether, as only a repository owner (or authorised committer) can contribute patches and therefore if you trust the account then you trust the content. </div><div><br></div><div>So how do we do this, and what overhead is there, if any? Admittedly, creating your own .deb packages, signing them and then making your repository accessible over the web isn't rocket science. How about the mirroring thing? Also, the does the index design for these solutions cater for the fact that you possibly have numerous origins publishing the same package/version? </div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">- The website can be made central, but should be avoided if possible.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What does this mean? This is sounding more and more like a system<br></blockquote><blockquote type="cite">that someone has to build and maintain. I'm *absolutely* in favour<br></blockquote><blockquote type="cite">of doing that, but someone is going to stump up the money for it.<br></blockquote><br><snip><br><br><blockquote type="cite"><blockquote type="cite">- Hayoo like search would be nice to have in a 2nd step.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Again, this is *great* idea, but someone, somewhere, covers the cost<br></blockquote><blockquote type="cite">of hackage/hayoo - the same applies here.<br></blockquote><br>If done right, the website will be just a fancy interface for the<br>index and/or archives fetched. Anyone should be able to host it, but<br>having a single well-known address is nice to have. That hypothetical<br>website would be a nice to have 2nd step on top of the foundation.<br>It doesn't have to exist from the beginning.</div></blockquote></div></body></html>