My two cents below... Sent from my iPad
> On 13 Jun 2014, at 06:32, "Tim Boudreau via smartos-discuss" > <[email protected]> wrote: > > 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 No. Not at all. This mythical list may also change from one QN to another. > - 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 This will bite you. This will not hold true for the same package installed on varying systems with different package installation combinations. > - 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 > This is list is nonsensical depending packages installed in varying combinations. It makes a great many assumptions about machine, state and intent. Bad idea. > 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. > This is a non trivial and a dangerous tool to write. You assume a fully knowable stable state, not so. People will try and depend on the reassuring lies this tool tells and There Will Be Blood. Or at least data loss and lost weekends. We really must stop assuming so much about the machine like this. > 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. > Oh (insert deity here) please no. This is really not what CouchDB is for and npm know it. Theres no way you want a CouchDB installation on each machine your run nor do you want the SPOF of a 'master' knowledge hub. there's actually a pkgsrc conference coming up in the UK if your interested in attending to discuss topics like the further. The truth that we should face is that system upgrades are a dangerous, legacy, foolish and fearful way of managing systems. You don't need to upgrade unless for the trivial cases. You can rebuild quickly and easily. Most of my platform can be rebuilt in 10 minutes, and I run a non trivial platform on the JPC. Databases are "fun"'to rebuild and I'll post my experiences to my blood over the next few weeks. Seriously though, please don't get distracted like this. There are amazing challenges to solve in SmartOS. This really isn't one of them IMHO. > -Tim > > smartos-discuss | Archives | Modify Your Subscription ------------------------------------------- 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
