Solved Should I care about "pkg check -d" output if my systems are installed and updated via ports system?

Status
Not open for further replies.
kpa said:
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
Click to expand...
Yes.
Code: 
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
Can you explain me that command and his output?
 
Look at pkg help query.
%n-%v are formatting commands.
and
Code: 
-e evaluation condition
B  for required shared libraries
b  for provided shared libraries
 
libgdal.so:
I compiled it as non-static library and reinstalled graphics/mapnik and the message with pkg check -d disappeared.
But does that mean pkg check does not find static libraries?
(the only additonal change - except the Makefile - I had to change in GDALmake.opt,in):
Code: 
-LIBGDAL_CURRENT  :=  20
+LIBGDAL_CURRENT  :=  2

it is a strange construction with the version number in this port.
 
talsamon said:
Look at pkg help query.
%n-%v are formatting commands.
and
Code: 
-e evaluation condition
B  for required shared libraries
b  for provided shared libraries
Click to expand...
Oh OK thank you. I saw that, then my question was more oriented in understand why that command will be helpful to understand the pkg check -d strange behaviour related with libgdk_pixbuf-2.0.so.0. Still wondering if it is a pkg bug or what.
 
Hanky-panky said:
Oh ok tnank you. I saw that, then my question was more oriented in understand why that command will be helpfull to understand the pkg check -d strange behaviour related with libgdk_pixbuf-2.0.so.0. Still wondering if it is a pkg bug or what.
Click to expand...

The "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 in 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.
 
kpa said:
The "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 in 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.
Click to expand...
Now everything is clear than case is not solved. The guy developing the 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 -dreport a broken system when actually it isn't.

So, now, considering FreeBSD is born to be installed and updated via ports system, we can conclude that sadly this OS still doesn't have a reliable binary package management system. To be reliable it should adapt himself to little misunderstanding like this and implement a different layer of check.

It is too simple just say: it isn't my fault.

PS: BTW, I do not pay for anything, so it is OK like this, obviously :)
 
I think there is something wrong with the graphics/gdal port (the 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.

Another thing is: few days ago security/cyrus-sasl has been updated and I got the "same" message from 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.
 
FWIW, this happens on libraries used by many other ports. I mean I have only installed a half-dozen ports and already I get a bunch of these bogus warnings.

Code: 
# 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

If pkg would just say what it is actually complaining about (libraries not passing pedantic validity tests) instead of saying in broken English that they are "missing", then we would not find it so distressing. I mean if it is doing more than just a missing-library check by design, then it needs to say that in the documentation and in its 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 ridicolous pkg autoremove command output.

Actually we just have a reliable pkg check -d output :p
 
Hanky-panky said:
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 ridicolous pkg autoremove command output.

Actually we just have a reliable pkg check -d output :p
Click to expand...

It'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.
 
kpa said:
It'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.
Click to expand...
I don't think so. In fact as I said, I'm sure I'm installed many of those ports directly using 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...
 
Hanky-panky said:
I don't think so. In fact as I said, I'm sure I'm installed many of those ports directly using 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...
Click to expand...

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).
 
kpa said:
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).
Click to expand...
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.

And Ok, even admitting I do have wrong expectation, I still think like it is on FreeBSD, autoremove is a dangerous and little accurate command.
 
Hanky-panky said:
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.
Click to expand...
Really?

Code: 
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.
 
Yep, 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.
 
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:

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
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.
 
ShelLuser said:
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:

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
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.
Click to expand...

Yeah, it's a matter of enforcing a policy in FreeBSD ports that is actually very hard to enforce properly. You can't ask everyone who is writing shared libraries to follow instructions to include those pesky ELF header sections that would identify them as shared libraries unambiguously. They files do work as shared libraries just fine without the SONAME tags and lot of the authors are not going to bother fixing their libraries just because FreeBSD wants them with the tags included.

I do remember suggesting to the pkg devs that we would add a new keyword to be used in pkg-plist that would identify a shared library but they didn't warm up to the idea at that point.
 
kpa said:
Yep, 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.
Click to expand...
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 dumb pkg autoremove works.

I remember the reaction to the 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?:p
 
he didn't admit anything. If there were to be a problem, it would be with 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.

[1] The cause of the problem in the example apparently is in the specific port.
[2] Shell user didn't illustrating autoremove issue so why are you trying to connect those those commands?
 
Status
Not open for further replies.
Back
Top