Re: [gentoo-dev] Moving packages to dev-vcs

[Brian Harring]

On Thu, Mar 04, 2010 at 10:08:06PM +0100, Sebastian Pipping wrote:
> 1. Copy
> =======
> - Duplicate any traces of dev-util/${PN} in profiles/ to dev-vcs/${PN}
>   (fgrep -Rw "dev-util/${PN}" profiles/)
>
> - Copy complete package dev-util/${PN} to dev-vcs/${PN}
>   (watch out CVS directories)
>
>
> 2. Switch
> =========
> - Update eclasses
>     fgrep -w "dev-util/${PN}" eclass/*.eclass
>
> - Update reverse dependencies
>     http://tinderbox.dev.gentoo.org/misc/dindex/dev-util/${PN}
>     http://tinderbox.dev.gentoo.org/misc/rindex/dev-util/${PN}
>                                         ^^^
>     fgrep -w "dev-util/${PN}" */*/*.ebuild

I'd suggest 

pquery --revdep dev-util/${PN} --raw --repo $PORTDIR

instead- throw in a '--attr inherited' if you want to look for 
eclasses that are implicated in addition, but it's a safer bet then 
relying on fgrep (since it's literal metadata searching) and doesn't 
have the potential for staleness tinderbox does.  Speed wise it'll be 
slower then grep, but not hugely so- reasonably up to date cache, it's 
<9s on my hardware so... there's no reason to not do it properly.


> - Append "move dev-util/${PN} dev-vcs/${PN}" line to
>   profiles/updates/1Q-2010
>   (must come last, described in [1])
>
>
> 3. Remove
> =========
> - Remove package dev-util/${PN} from CVS (as in [2])
>     cd dev-util
>     cvs rm -Rf ${PN}
>     cvs ci -m "dev-util/${PN}: Remove (renamed to dev-vcs/${PN})" ${PN}


Realistically, the dev *really* should be doing visibility scans 
after their efforts- yes bones does them too, but it's better to do 
the scan after to ensure any breakage is caught quickly.  Specifically 
via pkgcore-checks, I'd suggest running

pcheck -r $PORTDIR -c visibility '*'

prior to the move, and a dump of that commands output after the cvs rm 
invocation above.  Presuming everything was updated properly, the 
line count should be the same- output will vary slightly (previous 
complaints about dev-util/bzr being unavailable become dev-vcs/bzr 
unavailable specifically).

At least for my hardware, it's a 3.5 minute scan- so there really 
isn't a reason to *not* do this check (if the mips profiles were 
cleaned up/out prior it's more like 2.5 minutes on a sidenote)...


If folks are aware of alternate tools for doing these sort of checks 
in a timely fashion, feel free to pipe up also- I'm just suggesting 
the tools I know.


Random sidenote, anyone looked at using an alternate vcs to do the 
work, then proxy it back?  Specifically thinking of workflow like svk 
(or in this case hg cvs, 
https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS ).  The 
reason I ask is that via building the work up outside of cvs, then 
proxying the add/remove/modifications back into it, it should be 
possible to minimize the window of cvs breakage down to bare minimum 
while still getting the same level of QA validation for the changes.

That's assuming hg/cvs behaves sanely of course, and doing a checkout 
(tip as it were) from cvs into hg is fast enough to be viable.  Just a 
thought- djc, you got any comments on this usage of hg?

~harring