On Sun, 12 Jul 2015 18:48:32 -0700 Jeffrey Bouquet via freebsd-ports <freebsd-ports@freebsd.org> wrote
> Each time across major versions I find it convenient to install one or two > upgrades ( portupgrade and another, in this case) > > pkg install portupgrade [the installworld just completed an hour or two > ago] > > I use a > script reinstall.log pkg install portupgrade > > Because > the deinstalls called for are too numerous, no option to delay [ another SQL > field? ] > > For instance > > Those two reinstalls (major version) require removal of some 200-400 of which > I note manually 35 or so for immediate reinstall later today. > > In this case > Not trivial... > > serf > apr > subversion > w3m > firefox > vte > intltool > gnutls > gsasl > gtk2 > cups-base > ....... and twenty-odd others of the several hundred to be removed upon > the upgrade of portupgrade from another major version and another ruby > version to the latest one. > > So it is handy workaround, but I wonder if a combination of > 1... "delay these til later" > 2... "to be removed and logged in a /var/log/pkg-removed.log " file > 3... or some other scenario should make it more simple. > 4... a 2nd field in the 'to be removed' ... some removed because of the > ruby21 upgrade, some removed for some other reason... one could maybe > craft the request to pkg in a more orderly fashion if more information was > known at that step. Maybe. > > Obviously this does not occur in the usual course of upgrading... but those > to be removed could probably still be of use in the meantime... Not that is > is too problematic to reinstall them (usually but not always )... but it is > not as automatic as it maybe could be eventually. > > Thanks for reading. Just a thought. But what if you could NOT uninstall the many ports it uninstalls? For example; pkg install portupgrade .. the following ports/packages will be installed portupgrade BlahLib BlahApp BlahBlahApp 20mb additional space required [y]es [n]o Y .. the following 30,000 ports will be uninstalled (reclaims 10Tb) [y]es [no] N You chose NO (pkg(8) will ask this question again, next time it is used) I think something like this might be easier to implement. The only other warning that I can think that might need to be addressed, would be if one of the (proposed) deinstalls, was to satisfy the need to upgrade supporting lib(s), or applications. But in such a case, it seems it should just default to a no-op, and proceed as tho you had stated yes (for those only). Just a thought. --Chris > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
