# Upgrade packages.



## dndlnx (Aug 25, 2012)

I've been using the tool pkg_upgrade (bsdadminscripts), with packages from STABLE repos on a RELEASE system. It's worked quite well, I haven't run into any major problems. This is okay to do, I guess?

I was also curious, why this functionality isn't included in FreeBSD? You are given a choice to use binary packages, but no means to upgrade them. I believe OpenBSD has a switch to their pkg_add for upgrading packages.


----------



## Beastie (Aug 25, 2012)

Yes, using STABLE packages on RELEASE systems is perfectly fine as long as all dependencies are upgraded, thus avoiding incompatibility with libraries.

To upgrade packages I usually remove everything once in a while and reinstall everything. It's relatively fast on lightweight systems (like mine) and doesn't leave any traces that could potentially cause trouble later on.

The *pkg_** utilities are very old and I _guess_ people preferred to develop "extensions" as third-party applications/scripts than add new features given they would eventually be replaced. pkgng, the next generation package management system, supports upgrades.


----------



## jb_fvwm2 (Aug 25, 2012)

Here, reinstalling everything, even with a lightweight desktop, is out of the
question, too many ports installed.
The pkg_* utilities were fine for what they were... IMHO.  The pkg(ng) utility appears as good, maybe better, howsoever as I've been posting here and
in the freebsd-ports list, there are at least some users who view it as a much
more capable (in most ways) portupgrade+and+pkg_* replacement, and view its intended
(by a majority of those, probably, who are currently testing/deploying it) "default"
status as not necessary, as it (now) removes the flat files in /var/db/pkg (each directory a registration database of the port, so to speak) and
replaces that information (useful by portmaster, portupgrade, portmanager, one's
custom scripts, find/grep pipes, shell-aided file browsing...) with a front-end 
for which as yet only a few equivalents (the more common ones?) exist, concurrently
precluding an even-better portmaster, portupgrade... [ remaining issues omitted, 
straying too far from the topic of the thread. ]
/edit/
I posted a use case I found later today after this post to the
freebsd-ports list, where using a port that views/selects text
files and the shell for tab-completion I can find in about five
seconds flat the number and names of other ports already installed that the
dependency that I may/may not have installed, depend upon it, whereas using 
pkg query, not only choosing the particular port to check from
ports installed would take probably longer than that 5 seconds,
but then, the pkg query command syntax to view what is already
onscreen with the file viewer, shell, and command line, is not
yet in the EXAMPLES section of the manual, and it it were, would
take at least some parameters to the command to remember, whereas
now, the port that selects the directory in /var/db/pkg, also selects the +REQUIRED_BY with the up/down
arrows, (still at the non-desktop console), and so no switches/syntax
 delay to immediately ( five seconds in this case) obtain the information is incurred. 
So while pkg may be a great tool, the flat-files in /var/db/pkg are for at least some users, presently very useful
instead. (Inasmuch as that use case, is only one of about ten or
fifteen I use every year, maybe too many to abstract away into 
a API interface to the package registration status.)


----------



## dndlnx (Aug 25, 2012)

Did not know about pkgng, sounds promising. I will definitely take a look at that video! 

I enjoy watching tech talks on YouTube. They're relaxing at bedtime, haha. :r


----------



## jb_fvwm2 (Aug 25, 2012)

BTW the pkg_* tools replacement strategy only has appeared recently AFAIK.  My use case(s) above (regrettalby posted today not yesterday...) would preclude at least part of what may/may not occur in that regard...


----------

