Solved Squid pkg installation requirements

Greetings, if I try to install squid via pkg-install(8) on FreeBSD 10.1 stable I get a lot of dependencies that don't make sense to me. For example the installer wants to remove Apache package or upgrade a lot of other packages. May this be some broken pkg db that can be resolved or do I really have to remove and reinstall these packages? See the log from install, thanks for info:

Code:
# pkg install squid
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
The following 48 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
        mod_dav_svn-1.8.10_1
        apache24-2.4.10_1
        mod_php55-5.5.16
        libslang2-2.2.4_6
        mc-4.8.12_2

New packages to be INSTALLED:
        squid: 3.5.3
        mozjpeg: 2.1_2
        protobuf25: 2.5.0_4
        libxshmfence: 1.2
        libdevq: 0.0.2_1
        giflib: 5.0.6
        libx264: 0.142.2455_2
        speexdsp: 1.2.r3_1
        llvm35: 3.5.2

Installed packages to be UPGRADED:
        expat: 2.1.0_1 -> 2.1.0_2
        dbus: 1.8.6 -> 1.8.16
        dri: 7.6.1_4,2 -> 10.4.6,2
        libdrm: 2.4.17_1,1 -> 2.4.60,1
        hal: 0.5.14_27 -> 0.5.14_28
        polkit: 0.105_3 -> 0.105_5
        dbus-glib: 0.100.2_1 -> 0.104
        xcursorgen: 1.0.6 -> 1.0.6_1
        png: 1.5.18 -> 1.6.16
        gdk-pixbuf2: 2.28.2_1 -> 2.31.2_1
        tiff: 4.0.3_4 -> 4.0.4.b_1
        imlib2: 1.4.6_2,2 -> 1.4.6_6,2
        fontconfig: 2.11.0_3,1 -> 2.11.1,1
        firefox: 31.0,1 -> 37.0.1,1
        openbox: 3.5.2_5 -> 3.5.2_7
        subversion: 1.8.10_1 -> 1.8.13
        serf: 1.3.7 -> 1.3.8
        apr: 1.5.1.1.5.3_4 -> 1.5.1.1.5.4
        jabberd: 2.3.1 -> 2.3.1_7
        rrdtool: 1.4.8_2 -> 1.4.8_7
        cairo: 1.10.2_10,2 -> 1.12.18_1,2
        git: 2.1.0 -> 2.3.5
        librsvg2: 2.36.4_2 -> 2.40.9
        php55-gd: 5.5.16 -> 5.5.23
        lcms2: 2.6_3 -> 2.7
        ffmpeg: 2.2.4_5,1 -> 2.3.6_2,1
        gpac-libgpac: 0.5.0,1 -> 0.5.0_1,1
        schroedinger: 1.0.11_2 -> 1.0.11_3
        libtheora: 1.1.1_5 -> 1.1.1_6
        libvorbis: 1.3.4_1,3 -> 1.3.5,3
        libogg: 1.3.2,4 -> 1.3.2_1,4
        libgd: 2.1.0_4,1 -> 2.1.0_5,1
        p5-XML-Parser: 2.41_1 -> 2.41_2

Installed packages to be REINSTALLED:
        policykit-0.9_8 (direct dependency changed: glib)

The process will require 74 MiB more space.
83 MiB to be downloaded.

Proceed with this action? [y/N]:
 
Packages are build with the default port options. These options are preselected for maximal compatibility with other packages and do make sense for most people.

If you do not like the default preselection (i.e. for minimalism) the only way is to build the port yourself after selecting a custom combination of options.

If you want to build customized packages for machines on your local net for local deployment have a look on ports-mgmt/poudriere. This makes it possible to build custom configured packages on a (fast) amd64 multicore box for (slow) i386 boxes.

Regarding you question, there should be nothing wrong what you see, when installing Squid as a package from the public repository. If some needed packages are going to be deleted, just install them afterwards again. this should not be too much work when using packages.
 
Packages are build with the default port options. These options are preselected for maximal compatibility with other packages and do make sense for most people.
While this is absolutely true there's something fishy going on. Why on earth would the installation of www/squid trigger an upgrade of www/firefox?
 
Looks like he didn't upgrade his packages a long time.
Firefox is going to be lifted from version 31 to 37! :)
In meantime a lot of dependencies must have been changed. ;)
 
This is most likely the same problem as there is with emulation/i386-wine that keeps appearing as a dependency to random ports:

https://lists.freebsd.org/pipermail/freebsd-pkg/2015-April/001098.html

The problem in a nutshell is that some ports expose shared libraries that they shouldn't (meant for internal use by the application) and those libraries end up as dependencies to other ports that are completely unrelated. The proper way to deal with the libraries would be to use the BUNDLE_LIBS feature but it's so new that most of the ports haven't been fixed yet to use it.
 
Looks like he didn't upgrade his packages a long time.
Firefox is going to be lifted from version 31 to 37! :)
In meantime a lot of dependencies must have been changed. ;)

It's only a test box so that's why it's outdated - but it's a good pointer, I will update rest of packages and try to install again to see what happens.
 
Back
Top