Thanks, Jonathan, for the clear upgrade instructions! It seems like the upgrade situation, for those who would like to do it, could be helped by the community with a smidgin of coding and a bit of crowd-sourcing. Assuming the following assertions are true:
- The set of packages may NOT upgrade cleanly from QN to QN+1 is a relatively small percentage, and finite and knowable list - If a package may not upgrade cleanly from QN to QN+1 it is assumed that is also true of QN to QN+2 and so forth - Therefore, if that list is known, it is possible to determine if a system definitely can NOT be upgraded cleanly and which packages are at fault then some sort of reporting tool which allows users who do this sort of upgrade and find it does not go smoothly for a package can contribute that information to some sort of online repository for it, which pkgin (or a wrapper around it) can query as part of an upgrade would allow most (not all, but most) people to upgrade systems with reduced risk. It's the sort of thing that would be pretty trivial to write - probably take a similar approach to the one the NodeJS folks did with npm (one of the few uses of CouchDB I've seen where it was a really perfect fit - customers could optionally run a local mirror that accepts writes about packages if they're paranoid or maintain their own package repo, etc.). I'd imagine the integration with pkgin would actually be the hard part. -Tim ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
