1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

kde4 installation fails, libiodbc-3.52.7 conflicts with unixODBC-2.3.0

Discussion in 'Installation and Maintenance of Ports or Packages' started by dheerajsuthar, Jun 20, 2010.

  1. dheerajsuthar

    dheerajsuthar New Member

    Messages:
    45
    Thanks Received:
    0
    Hi!

    FreeBSD on my machine is: FreeBSD 8.0-RELEASE-p3. It's completely updated with freebsd-update and ports updated with portsnap update.

    I tried to install KDE4 (through ports) and got following errors during make:
    Code:
    libiodbc-3.52.7 conflicts with installed package(s): 
          unixODBC-2.3.0
    

    I chose default options during make config-recursive.

    Now, should I remove the said package? But will it not make installed packaged dependent on it unstable? Or is there any other way?

    Kindly help me on this issues as I am getting the same problem while installing many other ports too. Should I go ahead and remove conflict packages in such cases?

    Thanks in advance.
     
  2. Dereckson

    Dereckson New Member

    Messages:
    63
    Thanks Received:
    15
    Hi,

    I had the same issue on FreeBSD 8.0 installing GNOME, then KDE4. Here the fix and how to solve this kind of issues:

    (1) We need a general understanding of the problem. A google search on unixodbc and libiodbc explains its two drivers doing the same job, on a rather compatible way.

    (2) We need a local understanding of the problem, ie here "what port uses this unixODBC?". To get the answer, pkg_delete unixODBC-2.3.0 (pkg_delete won't delete anything used by other packages). It gives a list of the packages using the library. On my computer, it were:

    Code:
    scherzo# pkg_delete unixODBC-2.3.0
    pkg_delete: package 'unixODBC-2.3.0' is required by these other packages
    and may not be deinstalled:
    ekiga3-3.2.6_5
    gnome2-2.30.1_1
    opal3-3.6.6_6
    ptlib-2.6.5_2
    


    Okay, let's play Sherlock Holmes and read the Makefile of the ports.

    We can safely ignore gnome2, as it's a metaport. The result give us ekiga3 depends of opal3, which depends of ptlib.

    Code:
    cd /usr/ports/devel/ptlib
    make config
    

    grrr no option to disable odbc (but it's always valuable to try).

    Let's read the Makefile. Er... there is a --disable-odbc enabled. Something is wrong, oh it conflicts with ptlib26, it's one of those multiversions ports!

    Bye ptlib, a ls ../ptlib* tells us the correct package name is devel/ptlib26. Let's retry make config. Oh! An option to disable ODBC support.

    (3) We need to apply the solution/fix/workaround/kludge found:

    Code:
    cd /usr/ports/devel/ptlib26
    make deinstall clean
    make config #and we disable Use ODBC this time
    make reinstall clean
    


    Code:
    cd /usr/ports/devel/ptlib26
    make deinstall clean
    make config #and we disable Use ODBC this time
    make reinstall clean
    


    And let's deinstall unixodbc:

    Code:
    scherzo# cd /usr/ports/databases/unixODBC
    scherzo# make deinstall
    ===>  Deinstalling for databases/unixODBC
    ===>   Deinstalling unixODBC-2.3.0
    pkg_delete: package 'unixODBC-2.3.0' is required by these other packages
    and may not be deinstalled (but I'll delete it anyway):
    ekiga3-3.2.6_5
    gnome2-2.30.1_1
    opal3-3.6.6_6


    (4) Cleans the mess

    So this time, ptlib dependency have disappeared and unixODBC is deinstalled.

    A (now erroneous) dependency still exists between ports built against ptlib.

    To fix that, there is a tool called ''pkgdb''. Invoke it with the -F (short for --fix) options:

    Code:
    scherzo# pkgdb -F
    --->  Checking the package registry database
    [Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 808 packages found (         -2 +41) (...)......................................... done]
    Stale dependency: ekiga3-3.2.6_5 -> unixODBC-2.3.0 (databases/unixODBC):
    -> Deleted. (irrelevant)
    Stale dependency: gnome2-2.30.1_1 -> unixODBC-2.3.0 (databases/unixODBC):
    -> Deleted. (irrelevant)
    Stale dependency: opal3-3.6.6_6 -> unixODBC-2.3.0 (databases/unixODBC):
    -> Deleted. (irrelevant)


    Hop, it have cleaned our dependencies automatically.

    We can now resume our KDE compilation. It should resume with the libiodbc installation.
     
    tobe, mky, ericjansen and 6 others thank for this.
  3. dheerajsuthar

    dheerajsuthar New Member

    Messages:
    45
    Thanks Received:
    0
    Thanks will try that on my system.I really appreciate you kind detailed reply.
     
  4. chrisstankevitz

    chrisstankevitz New Member

    Messages:
    9
    Thanks Received:
    0
    Awesome post, thank you!

    Chris
     
  5. hedgehog

    hedgehog New Member

    Messages:
    191
    Thanks Received:
    18
    i think there is much better way to get such info without a risk of removing package :]
    Code:
    $ man pkg_info | egrep -A 1 '\-R'
         -R      For each of the specified packages, show the list of installed
                 packages which require it.


    pkg_info -R unixODBC-2.3.0
     
  6. ikbendeman

    ikbendeman Member

    Messages:
    258
    Thanks Received:
    8
    I don't think ekiga will build correctly without unixODBC, which is a problem since it's part of x11/gnome2. How hard would it be to configure devel/ptlib26 to build against databases/libiodbc instead of databases/unixODBC? I mean, they're supposed to be compatible from what I understand...
     
  7. ikbendeman

    ikbendeman Member

    Messages:
    258
    Thanks Received:
    8
    I got it to work! I edited /usr/local/ports/devel/ptlib26/Makefile and changed the following section:

    Code:
    line 53 | .if defined(WITH_ODBC)
    line 54 | CONFIGURE_ARGS+=     --enable-odbc
    line 55 | LIB_DEPENDS+=        odbc.1:${PORTSDIR}/databases/unixODBC
    line 56 | .esle
    line 57 | CONFIGURE_ARGS+=     --disable-odbc


    to the following:

    Code:
    line 53 | .if defined(WITH_ODBC)
    line 54 | CONFIGURE_ARGS+=     --enable-odbc
    line 55 | LIB_DEPENDS+=        iodbc.3:${PORTSDIR}/databases/libiodbc
    line 56 | .else
    line 57 | CONFIGURE_ARGS+=     --disable-odbc
    line 58 | .endif
     
  8. BostonDriver

    BostonDriver New Member

    Messages:
    44
    Thanks Received:
    0
    Any idea how to solve for a "package only" based system?

    /usr/ports doesn't even exist on this machine. I'd like to keep it this way until time permits to upgrade to stable.

    In my case, I have kde4 installed first, now I'm trying to get gnome2 installed. I'm on a fresh 8.1-Release system (amd64), installed from dvd iso found via FreeBSD torrents.

    I'm only using e.g. pkg_add -r gnome2 (as there are a few people who want to use gnome instead of kde4.)
     
  9. wblock@

    wblock@ Administrator Staff Member Administrator Moderator Developer

    Messages:
    11,503
    Thanks Received:
    2,212
    Make the modifications on a system with ports and build a package... The net result of packages is that you can't change them, they're binaries.

    Ports and the OS are not tied together, and as long as you don't change major versions of the OS, your installed applications will continue to work. So you can run newer ports without upgrading to -stable, or upgrade to -stable and continue to run your existing applications.
     
  10. BostonDriver

    BostonDriver New Member

    Messages:
    44
    Thanks Received:
    0
    The only system I have with ports is FreeBSD 4.10-Stable.

    As binaries, I'd (foolishly) expected the packages for -Release to just work together and keep out of each others way.

    If I had time, I'd just make 'em all via portupgrade.... I don't have time right now. This is also my first 64bit machine (at home anyway) so any packages I built from ports on one of the other 32bit systems would only be 32bit. I hoped the 64bit versions were pre-built, it would same me the effort until time permits and/or I really needed "make config" to change things to my specific needs.

    I guess for now, the gnome users are stuck with kde or just a shell lol

    Thanks for your suggestion
     
  11. Dereckson

    Dereckson New Member

    Messages:
    63
    Thanks Received:
    15
    (i) Compilation isn't so problematic : you can use another desktop environment during the few hours to 3 days needed to compile all, your system stays responsive, there are still free RAM.

    (ii) Fresh FreeBSD install + pkg_add -r gnome2 just works, the problem in this topic only concerns dual KDE/Gnome installations.

    (iii) You can start the install from packages, then compile the problematic port, then resume the install from packages. So you'll only have ONE port and its dependencies not yet installed through packages to compile. I'll be happy to assist you in the process.

    (iv) You can put the ports where you want: /home/bostondriver/ports, /tmp/ports are maybe some interesting locations outside your /usr partition.

    (v) You can use and upgrade -STABLE with a /usr/ports folder, freebsd-update doesn't touch this folder.
     
  12. BostonDriver

    BostonDriver New Member

    Messages:
    44
    Thanks Received:
    0
    Understood. pkg_add -r kde4 went flawlessly. Adding gnome2 (or trying to) a day or two later hit the issue.

    I actually added kde4 via sysinstall. I hit this gnome2/kde4 co-exist problem when also trying to use sysinstall. My attempt to add gnome2 came after the install install of kde and after some people complained that kde (via tightvnc) wasn't "working" as they are used to. (This is something I'm looking into, but out of scope of this thread.) So gnome was installed, or I tried to.

    Since prior posts, I used pkg_add -r gnome2 (not sysinstall) to see what happens. The problem in this thread still exists, but at least pkg_add didn't stop. "Enough" of gnome2 exists where gnome can be used (and does behave a lot better under vnc than kde.)

    We also have FreeBSD 8.1 running as a KVM guest, and there kde4 via tightvnc is awful! (Other vnc packages will be tried shortly.) Moving to gnome2 works far better, and users want to standardize on one, so I need gnome on this machine... at least until I can get kde to behave.
     
  13. ikbendeman

    ikbendeman Member

    Messages:
    258
    Thanks Received:
    8
    2013, still here....

    It looks like this is still a problem. My fix posted above still works... how do I contact the port maintainer and get them to fix this? libiodbc works just fine in place of unixODBC (I hear that unixODBC may work in place of libiodbc). Anyways, they both implement the same ABI but since I haven't yet learned SQL, I've yet to use either library while writing any of my own software.
     
  14. wblock@

    wblock@ Administrator Staff Member Administrator Moderator Developer

    Messages:
    11,503
    Thanks Received:
    2,212
    A port's maintainer can be found with the maintainer target:
    Code:
    # cd /usr/ports/databases/unixODBC
    # make maintainer
    


    For that port, maintainer is ports@, meaning there is no specific maintainer.

    It is usually preferable to enter a PR so the problem can be tracked.