On 28 July 2014 08:56, Ciaran McCreesh <[email protected]> wrote:
> > To me it seems like a simple data model bug that vdb does not get > > updated to reflect the new situation after step 2 above. > > Rewriting VDB won't help if the user doesn't sync at the right time. > Indeed. pkgmove has this problem solved with a mass of quarterly move files, but I'm not sure I'd want to have a) However many `depchange` entries required to make it happen linger on for all eternity in some cruft file just in case people don't sync more than once every 2 years: ( Yes, we still have an updates/1Q-2009 file for people stuck in a time warp who need change updates ) b) The burden of maintainers having to manually update that index. ( That's effectively what the -r1.1 and INSTALL_FROM proposals amount to ) The only saving grace here if we applied this strategy, is we could conceivably generate the index in an automated fashion due to ebuild edits usually being more obvious to an SCM than a move is. ( And you could conceivably generate them by simply comparing snapshot diffs without any SCM involvement ) -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
