• Bug#265494: libiodbc2 lost version in shlibs

    From Adrian Bunk@1:229/2 to All on Fri Aug 13 14:30:13 2004
    From: [email protected]

    Package: libiodbc2
    Version: 3.51.2-3
    Severity: grave


    It seems due to the cdbs conversion in 3.51.2-3, the shlibs
    file now generates an unversioned dependency.

    This should be fixed ASAP.

    It's also required to send RC bugs against all packages
    using libiodbc2 to build conflict with libiodbc2-dev (= 3.51.2-3)
    since they might get (some have already) broken dependencies on one
    or more architectures which might especially affect users upgrading
    from woody since the woody libiodbc2 would otherwise fulfill the
    dependency of a package built with 3.51.2-3 .


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Christian Hammers@1:229/2 to All on Fri Aug 13 20:50:13 2004
    From: [email protected]

    tags + moreinfo
    thanks

    Hello Adrian

    On 2004-08-13 Adrian Bunk wrote:
    It seems due to the cdbs conversion in 3.51.2-3, the shlibs
    file now generates an unversioned dependency.
    ...
    It's also required to send RC bugs against all packages
    using libiodbc2 to build conflict with libiodbc2-dev (= 3.51.2-3)
    since they might get (some have already) broken dependencies on one
    or more architectures which might especially affect users upgrading
    from woody since the woody libiodbc2 would otherwise fulfill the
    dependency of a package built with 3.51.2-3 .

    Can you explain me why/when this would break anything?
    * A user installs a Debian package depending on libiodbc2
    * The binary package would have versioned dependency to the sarge
    package -> ok
    * A user builds his own package
    * If he still has libiodbc-dev from woody my changes wouldn't affect
    anything and apart from that build-deps is the right way to force
    a specific dependency -> ok
    * A Debian buildd builds a package depending on iodbc
    * It would see the current shlibs and add an unversioned dependency
    to the "Depends:" line of the binary package. Or more probably a
    dependency just to the so-version which denotes the binary
    compatibility. -> ok

    What have I overlooked?

    Moreover unversioned shlib files are actually the default of debhelper
    and equally done by more than half of the ~600 /var/lib/dpkg/info/*.shlibs I have on my system. This makes me wonder why this should be so "grave"...

    thanks,

    -christian-


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Adrian Bunk@1:229/2 to Christian Hammers on Fri Aug 13 21:30:09 2004
    From: [email protected]

    On Fri, Aug 13, 2004 at 06:50:44PM +0200, Christian Hammers wrote:
    ...
    Hello Adrian

    Hi Christian,

    On 2004-08-13 Adrian Bunk wrote:
    It seems due to the cdbs conversion in 3.51.2-3, the shlibs
    file now generates an unversioned dependency.
    ...
    It's also required to send RC bugs against all packages
    using libiodbc2 to build conflict with libiodbc2-dev (= 3.51.2-3)
    since they might get (some have already) broken dependencies on one
    or more architectures which might especially affect users upgrading
    from woody since the woody libiodbc2 would otherwise fulfill the
    dependency of a package built with 3.51.2-3 .

    Can you explain me why/when this would break anything?
    * A user installs a Debian package depending on libiodbc2
    * The binary package would have versioned dependency to the sarge
    package -> ok

    * Not if the package was built with libiodbc2 3.51.2-3 installed.
    -> broken

    * A user builds his own package
    * If he still has libiodbc-dev from woody my changes wouldn't affect
    anything and apart from that build-deps is the right way to force
    a specific dependency -> ok

    * he wants to install the package on other computers
    * wrong dependency
    -> broken

    * A Debian buildd builds a package depending on iodbc
    * It would see the current shlibs and add an unversioned dependency
    to the "Depends:" line of the binary package. Or more probably a
    dependency just to the so-version which denotes the binary
    compatibility. -> ok

    * Does the program in this package really work with the five years old
    libiodbc2 2.50.3-1?

    What have I overlooked?

    I do not believe a program compiled with libiodbc2 3.51.2-3 works
    perfectly with the five years old libiodbc2 2.50.3-1 - and that's
    exactly what the current shlibs say.

    Moreover unversioned shlib files are actually the default of debhelper

    "dh_makeshlibs -V" is the common way to get versioned shlibs.
    (And debhelper wouldn't be an excuse for a broken package.)

    and equally done by more than half of the ~600 /var/lib/dpkg/info/*.shlibs I have on my system. This makes me wonder why this should be so "grave"...

    Whether shlibs in other packages are correct or broken is not the
    question (and checking a few of the other unversioned ones, they seem to
    be correct).


    Let me make a simple example:


    libqt3c102-mt-odbc in unstable was compiled with libiodbc2 3.51.2-3.
    Can you _guarantee_ it works with all older versions of libiodbc2?



    thanks,

    -christian-

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed



    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)