Is there a LTS version of these quarterly sets? Are all the sets ever created kept updated (with at least security updates)? The reason I attempted an upgrade was because the set I was using from 2012 didn’t look like had many updates when I ran update/upgrade, so was assuming it was no longer being maintained.
On Jun 1, 2014, at 11:21 PM, Filip Hajny <[email protected]> wrote: > Yeah, I’d have suggested ‘pkg_admin rebuild’ to check if it’s a real problem > or just a phantom one, but I was AFK last night. > > You can safely ignore (as in ‘yes’) the MySQL problem. It should never crop > up because mysql-client-5.5.24 and mysql-client-5.5.37 should be recognized > as different versions of the same package, and shouldn’t raise a conflict. > However, pkgin has its own slew of problems and updating to a different > quarterly set of packages may present a few other issues too. > > On that note in general, while updating an existing VM to a newer set > theoretically should work and in many cases does, it’s not recommended by > Joyent because you’re never insulated against changes that may have been made > in between the quarterly releases. Each quarter we build up the entire > package world from scratch from a new stable release - think of it as a new > major Ubuntu version. > > -F > > 1. 6. 2014 v 18:37, Anil Jangity <[email protected]>: > >> Looks like what I needed was “pkg_admin rebuild”. >> >> >> [root@shoe /var/db/pkgin]# pkgin fug >> calculating dependencies... done. >> mysql-client-5.5.37 (to be installed) conflicts with installed package >> mysql-client-5.5.24. >> proceed ? [y/N] y >> … >> >> Is the recommended thing to just say yes here >> or remove the old one and do it again? >> >> >> On Jun 1, 2014, at 9:31 AM, Anil Jangity <[email protected]> wrote: >> >>> No luck. >>> Should upgrading from one repo to the next work (and is it supported)? >>> >>> [root@shoe /opt/local/etc]# pkgin fug >>> calculating dependencies... done. >>> pkgin: scmgit-base-1.7.9.3 has no associated repository >>> >>> [root@shoe /opt/local/etc]# pkg_delete scmgit-base-1.7.9.3 >>> pkg_delete: No matching package for basename `scmgit-base-1.7.9.3' of >>> `scmgit-base-1.7.9.3' >>> >>> [root@shoe /opt/local/etc]# pkg_delete scmgit-base >>> pkg_delete: No matching package for basename `scmgit-base' of `scmgit-base' >>> [root@shoe /opt/local/etc]# >>> >>> It seems like the real packages are gone, but “pkgin” is just referencing >>> some old stale data? Where is this data stored? >>> >>> >>> On Jun 1, 2014, at 8:32 AM, Filip Hajny <[email protected]> wrote: >>> >>>> 1. 6. 2014 v 16:27, Anil Jangity via smartos-discuss >>>> <[email protected]>: >>>> >>>>> I am upgrading from an older repo (from 2012) to a newer one (2014Q1). >>>>> >>>>> [root@shoe /var/log]# pkgin fug >>>>> calculating dependencies... done. >>>>> pkgin: scmgit-base-1.7.9.3 has no associated repository >>>>> [root@shoe /var/log]# >>>>> >>>> >>>> Yes, things like that are just bound to happen if you try to upgrade an >>>> existing VM to a newer pkgsrc set. >>>> >>>>> [root@shoe /var/log]# pkgin list |grep scmgit >>>>> scmgit-base-1.7.9.3 GIT Tree History Storage Tool (base package) >>>>> >>>>> (I think when I ran the rm earlier, it *did* remove the files, but my >>>>> guess is, the package metadata is still stuck around somewhere. That’s >>>>> why it still shows up) >>>> >>>> You’ll have to use the standard core tools here I guess. Try `pkg_delete >>>> scmgit-base` and `pkgin -f up` to force a full update of the pkgin meta db. >>>> >>>> -F >>> >> > ------------------------------------------- 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
