[27043] trunk/base/portmgr

[Juan Manuel Palacios]

On Jul 16, 2007, at 2:24 PM, markd at macports.org wrote:

>
>
> If I understood this better perhaps I could write it up in the new  
> guide.
> When did this function become available?  What do we call it?  Remote
> repository?  Is it basically an internal macports repository for the
> enterprise?  Are the comments in mprsyncup and rsync.repos the only
> documentation we have?
>
> Mark
>


	Hi Mark!

	Thanks for inquiring about this, I was just about to write to you to  
request inclusion in the new guide ;-) The base/portmgr/mprsyncup and  
base/portmgr/rsync.repos files explain in their comments all that's  
needed to replicate our rsync mirrors locally, for instance on a  
server that wishes to supply local clients with faster sync/ 
selfupdate functionality off its own rsync server (not having to  
travel all the way to California if you're around the globe). Note  
that this is not exactly mirroring, as the example server would be  
doing the exact same thing rsync.macports.org is doing when setup  
with those two files, but independently of it (therefore "replicating").

	Vlad recently mailed portmgr about the "mirroring" topic, which is  
what prompted me to better explain the procedure in the files. The  
two thing I forgot to say to him in my reply is, one, that clients  
wanting to use the replicating server should be properly configured  
to do so:

-) rsync_server in macports.conf & rsync:// url in sources.conf:  
reset to point to your local server, not rsync.macports.org
-) rsync_dir in macports.conf & path component in rsync:// url in  
sources.conf: these shouldn't need any modifications if you follow  
the default and official repositories the MacPorts project offers on  
its own rsync server (coded in both base/portmgr/mprsyncup and base/ 
portmgr/rsync.repos); adapt accordingly otherwise (we assume you know  
what you're doing if you go to the trouble of offering other rsync  
repositories).

	And two, anyone wanting to replicate our configuration should  
consult with portmgr@ on an appropriate periodicity, we don't want to  
hammer the svn server too bad (every replicating server would be  
pulling from there). We refresh every 30 minutes at each x:00 & x:30,  
so we would appreciate it if 3rd parties didn't replicate more often  
than that and a bit off those two marks in any case. It would be  
great if all this information (including the comments in the two  
files in svn) were incorporated into the new guide!

	Lastly and with respect to the new guide's source: could you, Mark,  
please split it up in logical xml files (as you asked a while ago and  
as the current guide exists in svn) rather than having it in just one  
big monolithic file? Seems to me like it's much easier to handle like  
that.

	Regards,...


-jmpp

PS: Another topic that's up for inclusion in the new guide are the  
new ticketing guidelines that we're currently discussing on -devel at .  
I'll try to reply ASAP to the feedback I've received (thanks a  
bunch!) and will also setup a new Wiki doc (NewTracTicketing) to hold  
a mockup of the final design and consensus (currently smeared among a  
few mail posts, hard to track). Once that's done I'd like to see that  
text fully expanded into the new guide, please ;-), and  
NewTracTicketing removed, while the existing one (TracTicketing)  
should be turned into either a URL forward to the guide docs (once  
they're setup) or  simply slimmed down with a single "Read all about  
it here <url>" line.  Thanks!