OP
Hanky-panky
Guest
- Thread Starter
- #26
No problem with that library. Only problem with libgdk_pixbuf-2.0.so.0.Is there still a problem with that library inpkg check -d
?
No problem with that library. Only problem with libgdk_pixbuf-2.0.so.0.Is there still a problem with that library inpkg check -d
?
No problem with that library. Only problem with libgdk_pixbuf-2.0.so.0.
pkg query -e '%n=gdk-pixbuf2' %n-%v:%b
Yes.So which one? I was asking specifically about libgdk_pixbuf-2.0.so.0, does this produce any output now?
pkg query -e '%n=gdk-pixbuf2' %n-%v:%b
gdk-pixbuf2-2.31.7:libpixbufloader-jpeg.so
gdk-pixbuf2-2.31.7:libpixbufloader-png.so
gdk-pixbuf2-2.31.7:libgdk_pixbuf_xlib-2.0.so.0
gdk-pixbuf2-2.31.7:libpixbufloader-pcx.so
gdk-pixbuf2-2.31.7:libpixbufloader-ras.so
gdk-pixbuf2-2.31.7:libpixbufloader-xbm.so
gdk-pixbuf2-2.31.7:libpixbufloader-qtif.so
gdk-pixbuf2-2.31.7:libpixbufloader-icns.so
gdk-pixbuf2-2.31.7:libpixbufloader-jasper.so
gdk-pixbuf2-2.31.7:libpixbufloader-bmp.so
gdk-pixbuf2-2.31.7:libpixbufloader-gif.so
gdk-pixbuf2-2.31.7:libpixbufloader-ani.so
gdk-pixbuf2-2.31.7:libpixbufloader-tiff.so
gdk-pixbuf2-2.31.7:libpixbufloader-xpm.so
gdk-pixbuf2-2.31.7:libpixbufloader-ico.so
gdk-pixbuf2-2.31.7:libpixbufloader-wbmp.so
gdk-pixbuf2-2.31.7:libpixbufloader-pnm.so
gdk-pixbuf2-2.31.7:libpixbufloader-tga.so
pkg check -d
disappeared. pkg check
does not find static libraries?-LIBGDAL_CURRENT := 20
+LIBGDAL_CURRENT := 2
Oh OK thank you. I saw that, then my question was more oriented in understand why that command will be helpful to understand theLook atpkg help query
.
%n-%v
are formatting commands.
and
Code:-e evaluation condition B for required shared libraries b for provided shared libraries
pkg check -d
strange behaviour related with libgdk_pixbuf-2.0.so.0. Still wondering if it is a pkg
bug or what.Oh ok tnank you. I saw that, then my question was more oriented in understand why that command will be helpfull to understand thepkg check -d
strange behaviour related with libgdk_pixbuf-2.0.so.0. Still wondering if it is apkg
bug or what.
pkg check -d
stems from pkg(8) using only a surface level inspection of the shared libraries in a package. The inspection is kind of heuristic and if the library is broken in some ways, for example lacks the SONAME tag, it's not considered a provided shared library. Pkg used to do a dlopen(3) on every single file that looked like shared library to figure out all the other shared library dependencies but this caused huge problems because a shared library can have constructors that can be triggered automatically on dlopen(3) and there's also a possibility of a symbol clash because FreeBSD uses a flat 1-level namespace for symbol resolution. The change to switch to this surface level inspection was suggested by yours truly some time ago.Now everything is clear than case is not solved. The guy developing theThe "official" stance is that those ports are broken and should be fixed:
http://lists.freebsd.org/pipermail/freebsd-pkg/2015-October/001329.html
The strange behaviour inpkg check -d
stems from pkg(8) using only a surface level inspection of the shared libraries in a package. The inspection is kind of heuristic and if the library is broken in some ways, for example lacks the SONAME tag, it's not considered a provided shared library. Pkg used to do a dlopen(3) on every single file that looked like shared library to figure out all the other shared library dependencies but this caused huge problems because a shared library can have constructors that can be triggered automatically on dlopen(3) and there's also a possibility of a symbol clash because FreeBSD uses a flat 1-level namespace for symbol resolution. The change to switch to this surface level inspection was suggested by yours truly some time ago.
pkg
thing said developers should adapt the software to pkg
way of seeing things, then - like this - pkg
in hisself become unreliable becouse command pkg check -d
report a broken system when actually it isn't. MAJOR_VER
in the Makefile, ...). And why it is static compiled? But if I looked in the net problems with this ports existing for longer times. pkg check
. I had to recompile subversion and memcache - why portmaster this not recognize? If there were no discussion about pkg check
I had not seen that.# pkg check -d -n -a
Checking all packages: 100%
fusefs-ext4fuse has require a missing libraries: libfuse.so.2
gettext-tools has require a missing libraries: libintl.so.8
gettext-tools has require a missing libraries: libexpat.so.1
gmake has require a missing libraries: libintl.so.8
nano has require a missing libraries: libintl.so.8
opensmtpd has require a missing libraries: libasr.so.0
opensmtpd has require a missing libraries: libssl.so.8
opensmtpd has require a missing libraries: libevent-2.0.so.5
opensmtpd has require a missing libraries: libcrypto.so.8
pkg autoremove
command output. pkg check -d
output PEBKACSo now we hope they rething about actually IMHO ridicolouspkg autoremove
command output.
I want to bring this post to life and change his status to Solved, becouse after mine and other complains or maybe just becouse developers finally were been able to fix it, this problem went solved in 2016. So now we hope they rething about actually IMHO ridicolouspkg autoremove
command output.
Actually we just have a reliablepkg check -d
output
I don't think so. In fact as I said, I'm sure I'm installed many of those ports directly usingIt's not going to be rethought because there is nothing fix in it. Your view is just based in incomplete understanding on how the dependencies and automatically installed packages work.
make install
and BTW they are all sane and I didn't ask for removing them. How can you cope with a command that want to autoremove pretty much all Gnome becouse there is no gnome-meta installed or so. I call it dumb and at least dangerous and useless especially if used by newbie or so. Now we shouldn't hijack this thread...I don't think so. In fact as I said, I'm sure I'm installed many of those ports directly usingmake install
and BTW they are all sane and I didn't ask for removing them. How can you cope with a command that want to autoremove pretty much all Gnome becouse there is no gnome-meta installed or so. I call it dumb and at least dangerous and useless especially if used by newbie or so. Now we shouldn't hijack this thread...
Well, I still don't want to hijack this thread, then I want to say I used autoremove on debian apt-get and he never pretended to delete my all Gnome.You keep going on with this and I don't think you've even for a split second wondered if you might have some very wrong expectations of what pkg-autoremove(8) is for and how it should be used.
Go ahead and look at for example the apt-get package manager in Debian and Ubuntu, it has the exact same autoremove subcommand and it works exactly as it does with the FreeBSD pkg(8).
Really?Well, I still don't want to hijack this thread, then I want to say I used autoremove on debian apt-get and he never pretended to delete my all Gnome.
root@my-lt:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.6 (jessie)
Release: 8.6
Codename: jessie
root@my-lt:~# apt-get remove cinnamon
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
cinnamon
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 1,025 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 147673 files and directories currently installed.)
Removing cinnamon (2.2.16-5) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for libglib2.0-0:i386 (2.42.1-1+b1) ...
Processing triggers for libglib2.0-0:amd64 (2.42.1-1+b1) ...
Processing triggers for desktop-file-utils (0.22-1) ...
Processing triggers for mime-support (3.58) ...
root@my-lt:~# apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
caribou cinnamon-common cinnamon-control-center cinnamon-control-center-data cinnamon-l10n cinnamon-screensaver cinnamon-session
cinnamon-session-common cinnamon-settings-daemon cjs file-roller gir1.2-accountsservice-1.0 gir1.2-atspi-2.0 gir1.2-caribou-1.0
gir1.2-cinnamondesktop-3.0 gir1.2-cmenu-3.0 gir1.2-gdesktopenums-3.0 gir1.2-gkbd-3.0 gir1.2-gnomebluetooth-1.0
gir1.2-gnomedesktop-3.0 gir1.2-meta-muffin-0.0 gir1.2-networkmanager-1.0 gir1.2-nmgtk-1.0 gir1.2-polkit-1.0
gir1.2-upowerglib-1.0 gir1.2-xkl-1.0 gnome-accessibility-themes gnome-session-bin gnome-themes-standard
gnome-themes-standard-data gnustep-base-common gnustep-base-runtime gnustep-common gtk2-engines-pixbuf libatk-adaptor libaudio2
libcaribou-common libcaribou0 libcinnamon-control-center1 libcinnamon-desktop4 libcinnamon-menu-3-0 libcjs0 libgail-common
libgnustep-base1.24 libmng1 libmozjs185-1.0 libmuffin0 libnemo-extension1 libobjc4 libqt4-dbus libqtgui4 muffin-common nemo
nemo-data nemo-fileroller p7zip-full python-imaging python-lxml python-pam python-pyatspi python-pyinotify qt-at-spi unar
xwayland
0 upgraded, 0 newly installed, 64 to remove and 0 not upgraded.
After this operation, 108 MB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
root@macron:/usr/ports/sysutils/fusefs-rar2fs # pkg check -dn
Checking all packages: 100%
fusefs-rar2fs is missing a required shared library: libunrar.so
root@macron:/usr/ports/sysutils/fusefs-rar2fs # make run-depends-list
/usr/ports/archivers/libunrar4
/usr/ports/sysutils/fusefs-libs
root@macron:/usr/ports/sysutils/fusefs-rar2fs # pkg info -r libunrar4
libunrar4-4.2.4:
fusefs-rar2fs-1.15.1_1
root@macron:/usr/ports/sysutils/fusefs-rar2fs # date
Sun Dec 18 11:26:24 CET 2016
It wasn't really solved because it's not up to the pkg maintainers to solve it in the first place. And I can actually back up my words as well:
Or, in other words, the dependencies are fully installed and there are no broken dependencies yet pkg still picks things up as unresolved. However, as the others also mentioned: this isn't a problem related to pkg.Code:root@macron:/usr/ports/sysutils/fusefs-rar2fs # pkg check -dn Checking all packages: 100% fusefs-rar2fs is missing a required shared library: libunrar.so root@macron:/usr/ports/sysutils/fusefs-rar2fs # make run-depends-list /usr/ports/archivers/libunrar4 /usr/ports/sysutils/fusefs-libs root@macron:/usr/ports/sysutils/fusefs-rar2fs # pkg info -r libunrar4 libunrar4-4.2.4: fusefs-rar2fs-1.15.1_1 root@macron:/usr/ports/sysutils/fusefs-rar2fs # date Sun Dec 18 11:26:24 CET 2016
So, even in the wrong thread, you finally admit there is a problem. I can say we can even call it an improvement in how dumbYep, the actual autoremove functionality is 100% equal on both package managers as proven above. The differences between Debian and FreeBSD are in the organization of "ports", as far as I remember they don't use metaports but every application port/package includes the main application if at all possible. FreeBSD's way of organizing things has a side effect of causing the dependencies of metaports to be "abandoned" (because deleting the metaport does not mark the dependencies as non-automatic) if you ever delete the metaport that you installed and that's exactly what this fuss about autoremove is about.
pkg autoremove
works. pkg check -d
thread was initially the same: no problem at all, then they (developers, not fanguys) finally fixed it. So why all this FreeBSD fanguys deny problems just to "save" the "perfection" of them "religious" feeling in them idealistic minds? pkg check
[1], not pkg remove
[2]. Everyone is calling you a troll in the other thread and I'm having a hard time disagreeing with at this point.