Date: Tue, 21 Jul 2015 16:59:01 -0700 From: "Chris H" <bsd-lists@bsdforge.com> To: <freebsd-ports@freebsd.org> Subject: Re: pkg problem, not severe but tedious. Message-ID: <6b642bb4e0600d81175a28882cb2ffba@ultimatedns.net> In-Reply-To: <1436752112.28827.YahooMailBasic@web140903.mail.bf1.yahoo.com> References: <1436752112.28827.YahooMailBasic@web140903.mail.bf1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6b642bb4e0600d81175a28882cb2ffba>