Any alternative package manage tool other than 'pkg'?

E

erdos

I've been having increasing cases of broken states on my FreeBSD machines after installing a pkg using 'pkg'. The latest is that after installing 'awesome WM', firefox, xfe, etc are all throwing errors.

The question: Are there any other pkg management tool available other than 'pkg'?
 
No. Either use pkg(8), or build the ports. But then, the ports system just builds a package and installs it via the package manager, so it's the same thing.

You ought to actually state what errors you're getting, or at least try completely removing and reinstalling all packages. If everything you're installing is breaking, pkg(8) the problem lies a lot deeper than the package manager.
 
I installed 'awesome WM' on my freebsdFreeBSD 10.1, during the installation, it upgraded pkg sources, firefox, and bunch of other softwares. however, afterwards firefox, xfe, etc don't work anymore.

error received:
Code: 
$ xfe
/usr/local/lib/libpng16.so.16: version PNG16_0 required by /usr/local/lib/libFOX-1.6.so.0 not defined
$ firefox
XPCOMGlueLoad error for file /usr/local/lib/firefox/libxul.so:
/usr/local/lib/libpng16.so.16: version PNG16_0 required by /usr/local/lib/firefox/libxul.so not defined
Couldn't load XPCOM.

Launching awesome WM receiving errors:
Code: 
 error while running function
stack traceback:
[C]: in function 'load_image'
/usr/share/awesome/lib/gears/surface.lua:39: in function </usr/share/awesome/lib/gears/surface.lua:24>
(tail call): ?
(tail call): ?
/usr/share/awesome/lib/gears/wallpaper.lua:128: in function 'maximized'
/etc/xdg/awesome/rc.lua:76: in main chunk
error: /usr/share/awesome/lib/gears/surface.lua:39: Couldn't recognize the image file format for file '/usr/share/awesome/themes/default/background.png'
E: awesome: main:535: couldn't find any rc file

Checking for installed PNG:
Code: 
$ pkg info | grep png
png-1.6.20                     Library for manipulating PNG images
 
ldd(1)'s complaining. Reason? Because the ports you installed didn't set their "depends" correctly, or (more likely) you're whole system is "out of sync". I don't suppose you have a mix of ports you've built, followed by additional ports you pkg(8) installed? This is a frequent cause of the problem you describe.
Recommendation. Either build all your ports, or ask pkg to do them all. Not both. You should make that decision now, and then based on that decision; use that policy to update your entire ports() install base. Sorry, as I imagine you didn't want to hear that. :/
As to updating your ports; I'm currently using ports-mgmt/synth to update my base ports install. It'll build up a pkg(8) repository, updating everything on your system (ports wise) so the system can be updated, and synchronized. It's dead easy, and seems to do a pretty good job.
Just thought I'd mention it, in case it looked appealing, given your situation. :)

All the best.

--Chris
 
iI never install pkg through ports on this machine (thinkpad laptop), only through 'pkg'.

This issue, the way I see it, is that pkg has problem at checking and updating dependency. In this case, when I installed 'awesome wm' (<1MB) through pkg install, pkg updated many different packages (>100MB), including 'firefox', that makes me wonder: since 'awesome' has nothing to do with firefox. The error received seems to indicate that awesome couldn't open .png files, although 'PNG' is installed. I don't believe it's an issue with awesome, but PNG library somehow couldn't link png file.
 
erdos said:
i never install pkg through ports on this machine (thinkpad laptop), only through 'pkg'.

This issue, the way I see it, is that 'pkg' has problem at checking and updating dependency. In this case, when I installed 'awesome wm' (<1MB) through 'pkg install', pkg updated many different packages (>100MB), including 'firefox', that makes me wonder: since 'awesome' has nothing to do with firefox. The error received seems to indicate that awesome couldn't open .png files, although 'PNG' is installed. I don't believe it's an issue with awesome, but PNG library somehow couldn't link png file.
Click to expand...
Well, pkg(8) only "takes orders" from the packages, regarding dependencies, and records changes to your system. It's more a "messenger", than a "dictator"''. It's the packages responsibility to report any dependencies. I can say this with relative certainty, as I am currently Maintainer for about 100 ports. My guess, is that x11-wm/awesome required a png rendering library, and either installed it, installed an older version, or depended on something that depended on something, that depen... you get the picture. There's clearly a versioning issue. Another possibility is that one, or some of the programs that got upgraded were running at the time of the upgrade. This is always a bad choice. Because the programs are still living in memory, so there will ultimately be symbol collision, and all hell breaks loose. A reboot or closing, and re-opening the affected programs, usually clears things up. One final thought, is that ldd(1) wasn't run. Which means the libraries are not registered, and won't be found when the affected programs are run.
That's my take on it, FWIW.
Best of luck.

--Chris
 
Code: 
# pkg update
# pkg upgrade

You didn't update all of your installed packages at once, so some packages are built with library dependencies on version X, while others are build with version X+1 which is what's installed.

pkg repos are built all at once, so that everything is build using the same versions of everything. Thus, if you update the repo information for pkg (pkg update), then you should also upgrade all your installed packages. Alternatively, never run pkg update so that any new packages you install come from the same pkg repo. Or, switch to using the quarterly pkg repo instead of the latest one.

Basically, you need to keep everything in sync. Don't mix ports and pkgs, and don't mix repo versions.
 
I have a vanilla FreeBSD10.1 installation on my thinkpad laptop and haven't done much pkg installations since then.

My understanding is 'pkg' in FreeBSD is equivalent to 'apt' in Debian, or 'pacman' in Archlinux. Isn't 'pkg' supposed to keep track of dependencies when install a package? It seems to me that FreeBSD's 'pkg' does more bad than good for installing pkgs correctly. I've already learnt to issue:
# pkg update
# pkg upgrade
to fix a broken system. But still what's the point of pkg if I had to upgrade whole system to install a package? And above commands still didn't fix 'awesome' problem, I still couldn't use it due to error mentioned.
 
my bad about 'pacman': I never used Arch Linux, I meant to compare pkg with 'apt' or 'XBPS', but guess pplpeople know Debian/Arch linux more than void Linux ( which was created by a former NetBSD maintainer). I've never run into serious problem with either package management in those two distros. But on three installations of FreeBSD on my home pc/laptops, every machine had become broken by 'pkg' after a while.
 
Being a rolling-release distro, I'd presume Void handled things the same way as every other rolling-release package system--if you want to upgrade one package, you're strongly encouraged to upgrade them all, lest things break. Debian avoids this because they only update their stable package repositories once every couple years.

In any case, I'll be blunt: if you've broken three installs, you're obviously doing something terribly wrong. pkg(8) has worked fine for me on two different installs for over a year, and I'm hardly alone.
 
Is FreeBSD also considered on a rolling-release?

Are there any way to freeze the FreeBSD repo on my box rather than being forced to update them all the time? I'd prefer to have a stable system than a cutting edge but somewhat broken system. Newest aren't the greatest sometimes - as an example, the new 'xfe' on my box is rather buggy comparing with previous stable version.
 
erdos said:
Is FreeBSD also considered on a rolling-release?

Are there any way to freeze the FreeBSD repo on my box rather than being forced to update them all the time? I'd prefer to have a stable system than a cutting edge but somewhat broken system. Newest aren't the greatest sometimes - as an example, the new 'xfe' on my box is rather buggy comparing with previous stable version.
Click to expand...

FreeBSD operating system is definitely not rolling release, the releases are feature locked with a guaranteed stable API/ABI that won't change between the minor releases. The ports(7) system however is rolling release because there is not enough manpower to do back porting of security and other fixes for an extended period of time to locked in place versions of key software such as Perl. The new quarterly ports/packages is an attempt to something in between, the quartely branch stays locked only for quarter of a year and receives back ported fixes for that period of time and is then recreated from the head branch when the period comes to an end.
 
erdos said:
I have a vanilla FreeBSD10.1 installation on my thinkpad laptop and haven't done much pkg installations since then.

My understanding is 'pkg' in FreeBSD is equivalent to 'apt' in Debian, or 'pacman' in Archlinux. Isn't 'pkg' supposed to keep track of dependencies when install a package? It seems to me that FreeBSD's 'pkg' does more bad than good for installing pkgs correctly. I've already learnt to issue:
# pkg update
# pkg upgrade
to fix a broken system. But still what's the point of pkg if I had to upgrade whole system to install a package? And above commands still didn't fix 'awesome' problem, I still couldn't use it due to error mentioned.
Click to expand...

pkg(8) is virtually identical in usage to aptitude on Debian.

If you never run aptitude update and just use aptitude install to add new software, everything works well.

If you run aptitude update on a regular basis, but only ever use aptitude install to install new software, eventually you will run into issues and will be forced to upgrade all installed packages (via aptitude safe-ugprade).

If you run aptitude update on a regular basis, and use aptitude safe-upgrade to upgrade everything all at once, before running aptitude install to install new software, then everything works well.

IOW, if you keep your local "repo" version the same as the remote "repo" version when installing software, then everything works. If you let the local and remote "repo" versions get out-of-sync, you'll run into problems.

No different with pkg(8).

If you never run pkg update (or use a remote repo that never/rarely changes) and just use pkg install to add new software, everything works well.

If you run pkg update on a regular basis, but only ever use pkg install to install new software, eventually you will run into issues and will be forced to upgrade all installed packages (via pkg upgrade).

If you run pkg update on a regular basis, and use pkg upgrade to upgrade everything all at once, before running pkg install to install new software, then everything works well.

IOW, keep your local pkg repo database in sync with the remote pkg repo database, and keep all of your installed applications up-to-date with what's in the remote pkg repo database.
 
What can be confusing and a little error prone is that pkg() updates the repository information whenever you run
Code: 
pkg install
unless you suppress this with the '-U' parameter.
 
That's also configurable in pkg.conf(5):

Code: 
REPO_AUTOUPDATE: boolean
          When true, automatically check for and download updates to
          /var/db/pkg/repo.sqlite when running one of: pkg fetch, pkg
          install, pkg rquery, pkg search, pkg upgrade,    or pkg version
          -R.  Default:    YES.
 
You must log in or register to reply here.
Back
Top