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