On Sun, Jul 27, 2014 at 5:27 PM, Kent Fredric <[email protected]> wrote: > > 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
Does it matter? If a user never syncs again, they'll have a broken package (though portage won't realize it). If they wait until the package is removed from the tree before syncing then they'll still have a broken package. If the broken package happens to work for them, then the user won't care, and if it doesn't work for them, they'll sync in the updates one way or another (using an overlay if necessary). As far as I can tell, the only thing that is needed for this to work is for portage to be able to detect when an installed package dependency changes in the repository, and this could be facilitated by metadata. Maintainers would then revbump when a change can't be correctly handled, and they won't revbump when it can be. Do we have to guarantee that users who don't sync before a PV is removed get all updates to that PV if they have it installed when they eventually do sync? If I have some package installed that was treecleaned a year ago and it depends on udev then obviously it won't know anything about the new virtual - we live with that already without too many problems. Bottom line is that bad things happen if you hang onto packages that aren't maintained in some repository (possibly your overlay maintained by yourself). Rich
