GSoC Update: Registry

[Juan Manuel Palacios]

On Aug 3, 2007, at 4:19 PM, Chris Pickel wrote:

>>
>> 	How would that script be run? Each user manually at their own  
>> discretion? Or through some upgrade glue internal to MacPorts? I  
>> would very much prefer the latter approach, something like my  
>> "upgrade" target in base/Makefile.in (later on I'll remove all  
>> that code once we consider enough time has gone by to upgrade most  
>> of our user base to the macports namespace, in the mean time I'm  
>> sure we can share that target for other upgrade purposes).
>
> I had assumed an 'upgrade' target. However, since the script is  
> external to the Makefile, it wouldn't be difficult to do the second  
> method


	When I said "internal to MacPorts" I was referring precisely to the  
upgrade target in base/Makefile.in (as opposed to a tool, some  
separate script, that the user has to run manually after reinstalling  
MacPorts, which is what I meant by the implied "external"). So I  
guess we're in "violent agreement" there ;-)


> - i.e., at the end of mportinit, if file doesn't exist $ 
> {registry.path}/registry/, source ${prefix}/share/macports/scripts/ 
> reg_upgrade.tcl


	I would personally prefer a Makefile target, MacPorts innards are  
already quite filled with upgrade hacks here and there to account for  
stuff we've changed in non backwards compatible ways throughout our  
history; but I'll let you be the judge for what'll work best for your  
upgrade. On a related note, cleaning up the legacy cruft would be  
lovely, IIRC registry1.0 is filled with it and I'm positive we don't  
need it any longer ;-)

>
> OK. So to be clear, if I commit to trunk, there will be no trouble  
> with keeping it out of 1.5.1? Then I'll go ahead and commit.


	There shouldn't be, regardless of svnmerge.py if I have careful and  
detailed eyes. But now that you mention it, it's no secret that  
waiting until I merge to release_1_5 and release 1.5.1 will only make  
my life easier (I do have to analyze trunk to figure out what I'll  
merge). So if you're not pressed to commit then I guess waiting a  
couple of days will not hurt.

>
>>
>> 	I'd encourage you to do the same for registry2.0 and later on  
>> figure out what tool we use to produce the docs if doxygen can't  
>> handle the tcl format, what matters the most is that the  
>> documentation is already there in place.
>
> Alright. I think I'll probably use the doxygen style, but use /*  
> instead of /**. Tools won't detect it as documentation, so they  
> won't screw up when they try to associate it with the function  
> signature ;)


	Most cool! Having the documentation already in place will rock,  
later on we'll figure out how to extract it on an automated basis.

>
>
> Chris


	Thanks for this great work, Chris. Keep it up! Regards,...


-jmpp