pkg problem, not severe but tedious.
bsd-lists at bsdforge.com
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 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
> I use a
> script reinstall.log pkg install portupgrade
> 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...
> ....... 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
the following 30,000 ports will be uninstalled (reclaims 10Tb)
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 freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
More information about the freebsd-ports