I think it wouldn't be bad to point to /usr/share/doc/${PF}/html/ref/upgrade/process.html respective http://www.oracle.com/technology/documentation/berkeley-db/db/ref/upgrade/process.html, depending, if the doc use flag is set or not. Please do so or drop a line, if you want me to do it.
feel free to add what you would like to see.
carlo: it should probably be added to the package that is changing between slots of berkdb. If you still want it, go ahead and add it yourself.
*** Bug 212422 has been marked as a duplicate of this bug. ***
No response from carlo. It does need to be on the actual app, because berkdb dump+restore isn't valid in many cases anyway (need to use the app-specific dump/restore because of key issues). Or just keep the app linked to the same slot of DB.
(In reply to comment #4) > No response from carlo. Yeah - sorry - I tend to loose track of my bugs, unfortunately. > It does need to be on the actual app, because berkdb dump+restore isn't valid > in many cases anyway (need to use the app-specific dump/restore because of key > issues). Or just keep the app linked to the same slot of DB. Right, it's not a solution, but raises awareness. Iirc I opened the bug because of a forums post, seeing someone struggling with bdb updates and not understanding that his db's wouldn't be updated transparently. Your last sentence implies to keep n++ bdb versions forever... :/ Also Portage's current --depclean functionality stupidly only keeps the latest slot, so it's likely users get bitten.
