pkg problem, not severe but tedious.

Chris H bsd-lists at
Tue Jul 21 23:58:30 UTC 2015

On Sun, 12 Jul 2015 18:48:32 -0700 Jeffrey Bouquet via freebsd-ports
<freebsd-ports at> 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
20mb additional space required
[y]es [n]o
the following 30,000 ports will be uninstalled (reclaims 10Tb)
[y]es [no]
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.


> _______________________________________________
> freebsd-ports at mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at"

More information about the freebsd-ports mailing list