Headsup: ncurses soname bump 5 to 6 - Debian

This is a discussion on Headsup: ncurses soname bump 5 to 6 - Debian ; [+dickey] On Thu, Sep 18, 2008 at 8:45 AM, Florian Weimer wrote: >>> So the obvious solution seems to me then to build ncurses twice, >>> providing both libncurses5 and libncurses6 packages. What point do I miss? >> >>The crashes ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 55 of 55

Thread: Headsup: ncurses soname bump 5 to 6

  1. Re: Headsup: ncurses soname bump 5 to 6

    [+dickey]

    On Thu, Sep 18, 2008 at 8:45 AM, Florian Weimer wrote:
    >>> So the obvious solution seems to me then to build ncurses twice,
    >>> providing both libncurses5 and libncurses6 packages. What point do I miss?

    >>
    >>The crashes that will happen when both are loaded in a
    >>process's address space.
    >> ... and they couldn't add mouse-wheel support without breaking ABI ?

    >
    > AFAICT, the issue is that there aren't enough bits in an int to express
    > all the button events in the same way as before. The new ABI reshuffles
    > the bits to make more room.
    >
    > It should be possible to make this change in a less invasive way.


    A possible problem case is: an app built against version X of ncurses
    tries to load a shared library built against version X+1 of ncurses.
    e.g. a CAD vendor ships a binary app linked itself against ncurses.so.5
    and also via a library in the distro against ncurses.so.6.
    But are there any libraries in linux distros that use ncurses?
    As it turns out, yes. On my system, I see rather a few:

    gstreamer-0.10/libgstaasink.so
    gstreamer-0.10/libgstcacasink.so
    libaa.so.1.0.4
    libcaca.so.0.99.13
    libcaca++.so.0.99.13
    libcwidget.so.3.0.0
    libedit.so.2
    libform.so.5.6
    libformw.so.5.6
    libggi.so.2.0.2
    libguilereadline-v-12.so.12.3.1
    libmenu.so.5.6
    libmenuw.so.5.6
    libpanel.so.5.6
    libpanelw.so.5
    libvte.so.9.2.17
    libzephyr.so.3.0.0
    python2.5/lib-dynload/readline.so
    python-support/python-vte/python2.4/gtk-2.0/vtemodule.so

    So if a binary app happens to link in any of those and also ncurses itself,
    there's a potential conflict. I don't know if there's an actual conflict, I
    haven't looked.

    I didn't see any recent discussion about abi stability
    http://lists.gnu.org/mailman/listinfo/bug-ncurses
    If there is a realistic problem case, perhaps we should also discuss it there.
    - Dan


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: Headsup: ncurses soname bump 5 to 6

    On Thu, 18 Sep 2008, Dan Kegel wrote:

    > [+dickey]
    >
    > On Thu, Sep 18, 2008 at 8:45 AM, Florian Weimer wrote:
    >>>> So the obvious solution seems to me then to build ncurses twice,
    >>>> providing both libncurses5 and libncurses6 packages. What point do I miss?
    >>>
    >>> The crashes that will happen when both are loaded in a
    >>> process's address space.
    >>> ... and they couldn't add mouse-wheel support without breaking ABI ?

    >>
    >> AFAICT, the issue is that there aren't enough bits in an int to express
    >> all the button events in the same way as before. The new ABI reshuffles
    >> the bits to make more room.


    that, and the extended colors.

    >> It should be possible to make this change in a less invasive way.


    Then in that case, it should be possible for someone to submit a patch
    which does that.

    > A possible problem case is: an app built against version X of ncurses
    > tries to load a shared library built against version X+1 of ncurses.


    ....and some do, and some don't use libtic and/or libterm.

    > I didn't see any recent discussion about abi stability
    > http://lists.gnu.org/mailman/listinfo/bug-ncurses
    > If there is a realistic problem case, perhaps we should also discuss it there.
    > - Dan


    I don't recall anyone mentioning it recently (other than this thread, for
    example). The ABI=6 code's been there a few years.

    --
    Thomas E. Dickey
    http://invisible-island.net
    ftp://invisible-island.net


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: Headsup: ncurses soname bump 5 to 6

    * Thomas Dickey:

    > Then in that case, it should be possible for someone to submit a patch
    > which does that.


    Yes, but ...

    > I don't recall anyone mentioning it recently (other than this thread,
    > for example). The ABI=6 code's been there a few years.


    .... from the upstream POV, this would be another ABI transition.


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: Headsup: ncurses soname bump 5 to 6

    On Thu, 18 Sep 2008, Florian Weimer wrote:

    > * Thomas Dickey:
    >
    >> Then in that case, it should be possible for someone to submit a patch
    >> which does that.

    >
    > Yes, but ...
    >
    >> I don't recall anyone mentioning it recently (other than this thread,
    >> for example). The ABI=6 code's been there a few years.

    >
    > .... from the upstream POV, this would be another ABI transition.


    If there's no patch, there's nothing to discuss, then.

    --
    Thomas E. Dickey
    http://invisible-island.net
    ftp://invisible-island.net


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: Headsup: ncurses soname bump 5 to 6

    On Thu, Sep 18, 2008 at 13:40:14 -0700, Dan Kegel wrote:

    > On Thu, Sep 18, 2008 at 1:12 PM, Thomas Dickey wrote:
    > >> .... from the upstream POV, this would be another ABI transition.

    > >
    > > If there's no patch, there's nothing to discuss, then.

    >
    > Going forward, though, can you avoid potential issues like this
    > by maintaining better ABI compatibility between versions?
    > i.e. when you add a libncurses.so.7, can you make it so
    > that all apps that linked against libncurses.so.6 still continue
    > to work without recompilation?


    This doesn't make any sense. If all apps linked against the previous
    version continued to work without recompilation, it wouldn't be an
    incompatible ABI change, and so wouldn't require a SONAME bump.

    Cheers,
    Julien


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: Headsup: ncurses soname bump 5 to 6

    On Thu, Sep 18, 2008 at 1:12 PM, Thomas Dickey wrote:
    >> .... from the upstream POV, this would be another ABI transition.

    >
    > If there's no patch, there's nothing to discuss, then.


    Going forward, though, can you avoid potential issues like this
    by maintaining better ABI compatibility between versions?
    i.e. when you add a libncurses.so.7, can you make it so
    that all apps that linked against libncurses.so.6 still continue
    to work without recompilation?
    - Dan


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Re: Headsup: ncurses soname bump 5 to 6

    On Thu, Sep 18, 2008 at 01:40:14PM -0700, Dan Kegel wrote:
    > On Thu, Sep 18, 2008 at 1:12 PM, Thomas Dickey wrote:
    > >> .... from the upstream POV, this would be another ABI transition.

    > >
    > > If there's no patch, there's nothing to discuss, then.

    >
    > Going forward, though, can you avoid potential issues like this
    > by maintaining better ABI compatibility between versions?
    > i.e. when you add a libncurses.so.7, can you make it so
    > that all apps that linked against libncurses.so.6 still continue
    > to work without recompilation?


    Or even better, make it totally ABI compatible, thus not even bump the
    SO version.

    Mike


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: Headsup: ncurses soname bump 5 to 6

    On Thu, Sep 18, 2008 at 2:03 PM, Julien Cristau wrote:
    >> Going forward, though, can you avoid potential issues like this
    >> by maintaining better ABI compatibility between versions?
    >> i.e. when you add a libncurses.so.7, can you make it so
    >> that all apps that linked against libncurses.so.6 still continue
    >> to work without recompilation?

    >
    > This doesn't make any sense. If all apps linked against the previous
    > version continued to work without recompilation, it wouldn't be an
    > incompatible ABI change, and so wouldn't require a SONAME bump.


    You still need an SONAME burp if some apps linked against the
    newer library (say, those using new features) would fail with the older one.
    i.e. unless a change is both forward and backwards compatible,
    you can't get away without some sort of burp. (Or am I confused?)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: Headsup: ncurses soname bump 5 to 6

    On Thu, 18 Sep 2008, Julien Cristau wrote:

    > On Thu, Sep 18, 2008 at 13:40:14 -0700, Dan Kegel wrote:
    >
    >> On Thu, Sep 18, 2008 at 1:12 PM, Thomas Dickey wrote:
    >>>> .... from the upstream POV, this would be another ABI transition.
    >>>
    >>> If there's no patch, there's nothing to discuss, then.

    >>
    >> Going forward, though, can you avoid potential issues like this
    >> by maintaining better ABI compatibility between versions?
    >> i.e. when you add a libncurses.so.7, can you make it so
    >> that all apps that linked against libncurses.so.6 still continue
    >> to work without recompilation?

    >
    > This doesn't make any sense. If all apps linked against the previous
    > version continued to work without recompilation, it wouldn't be an
    > incompatible ABI change, and so wouldn't require a SONAME bump.


    agree - I don't know how to guarantee that five years from now there'd
    be no ABI change - the best I can do is maintain API compatibility.

    --
    Thomas E. Dickey
    http://invisible-island.net
    ftp://invisible-island.net


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Re: Headsup: ncurses soname bump 5 to 6

    On Thu, Sep 18, 2008 at 02:07:19PM -0700, Dan Kegel wrote:
    > On Thu, Sep 18, 2008 at 2:03 PM, Julien Cristau wrote:
    > >> Going forward, though, can you avoid potential issues like this
    > >> by maintaining better ABI compatibility between versions?
    > >> i.e. when you add a libncurses.so.7, can you make it so
    > >> that all apps that linked against libncurses.so.6 still continue
    > >> to work without recompilation?


    > > This doesn't make any sense. If all apps linked against the previous
    > > version continued to work without recompilation, it wouldn't be an
    > > incompatible ABI change, and so wouldn't require a SONAME bump.


    > You still need an SONAME burp if some apps linked against the
    > newer library (say, those using new features) would fail with the older one.
    > i.e. unless a change is both forward and backwards compatible,
    > you can't get away without some sort of burp. (Or am I confused?)


    This is not how SONAMEs are used, no. SONAMEs are changed when an
    application built against the old version of the library can't be used with
    the new version of the library. When the converse is true, that a new
    version of the application can't be used with the old version of the
    library, that's signaled by other means (shlibs, components of the library
    filename that aren't represented in the SONAME, versioned symbols, etc).

    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    Ubuntu Developer http://www.debian.org/
    slangasek@ubuntu.com vorlon@debian.org


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Re: Headsup: ncurses soname bump 5 to 6

    Le jeudi 18 septembre 2008 à 17:29 -0400, Thomas Dickey a écrit :
    > agree - I don't know how to guarantee that five years from now there'd
    > be no ABI change - the best I can do is maintain API compatibility.


    You can maintain ABI compatibility by using opaque structures by using
    constructor/getter/setter/destructor functions, from the very beginning.

    --
    .''`.
    : :' : We are debian.org. Lower your prices, surrender your code.
    `. `' We will add your hardware and software distinctiveness to
    `- our own. Resistance is futile.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBI0+5crSla4ddfhTMRAuekAKDcERU1O6OKV3D4gyltas 3g1FQPRQCgzGms
    C7gniQq4Qlz+P30W7iKUEgs=
    =pCUe
    -----END PGP SIGNATURE-----


  12. Re: Headsup: ncurses soname bump 5 to 6

    On Fri, 19 Sep 2008, Josselin Mouette wrote:

    > Le jeudi 18 septembre 2008 à 17:29 -0400, Thomas Dickey a écrit :
    >> agree - I don't know how to guarantee that five years from now there'd
    >> be no ABI change - the best I can do is maintain API compatibility.

    >
    > You can maintain ABI compatibility by using opaque structures by using
    > constructor/getter/setter/destructor functions, from the very beginning.


    (a) the details under discussion don't fall into that category

    (b) ncurses-current provides a feature for opaque WINDOW struct,
    whose default could be made part of the Debian flags, but has the
    potential for breaking existing code.

    (c) the beginning of ncurses is well before the current thread...

    --
    Thomas E. Dickey
    http://invisible-island.net
    ftp://invisible-island.net

  13. Re: Headsup: ncurses soname bump 5 to 6

    On mar, 2008-09-16 at 21:21 +0200, Daniel Baumann wrote:
    > just a quick note: after lenny, ncurses will bump soname major from 5
    > to
    > 6 in order to make mouse wheels work. The transition will be big, but
    > can be entirely handled with binNMUs only and this is what this mail
    > is
    > about:


    btw, wrt to that issue, and with LSB in head, it could be worth to
    synchronize with other distros, and see what they think about this.

    I guess using distributions@lists.freedesktop.org for that would be a
    good idea.

    Cheers,
    --
    Yves-Alexis

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEABECAAYFAkjUyRwACgkQTUTAIMXAW65cCgCfbAKREfhFre q/kRwQLgYshtwB
    9AEAoJkjF1RU20nit0Hw7sTszRrQiu6X
    =BBZ0
    -----END PGP SIGNATURE-----


  14. Re: Headsup: ncurses soname bump 5 to 6

    On Thu, 18 Sep 2008 23:03:25 +0200
    Julien Cristau wrote:

    > On Thu, Sep 18, 2008 at 13:40:14 -0700, Dan Kegel wrote:
    >
    > > On Thu, Sep 18, 2008 at 1:12 PM, Thomas Dickey wrote:
    > > >> .... from the upstream POV, this would be another ABI transition.
    > > >
    > > > If there's no patch, there's nothing to discuss, then.

    > >
    > > Going forward, though, can you avoid potential issues like this
    > > by maintaining better ABI compatibility between versions?
    > > i.e. when you add a libncurses.so.7, can you make it so
    > > that all apps that linked against libncurses.so.6 still continue
    > > to work without recompilation?

    >
    > This doesn't make any sense. If all apps linked against the previous
    > version continued to work without recompilation, it wouldn't be an
    > incompatible ABI change, and so wouldn't require a SONAME bump.


    Take a different example - a library that retains all symbols during
    the current SONAME, migrating some into a "deprecated" section/file and
    adding new ones as bug fixes. When those deprecated symbols are finally
    removed, a SONAME bump is required. (This is the case for qof, glib2.0
    and gtk2.0 use deprecated symbols too.) The symbols are versioned so
    that reverse dependencies can depend on the correct version.

    The library can support compile-time --no-deprecated option
    to ./configure so that all reverse dependencies can be tested upstream
    against the new ABI *before* the modified version of the library is
    released upstream.

    Those reverse dependencies then make a release before the next library
    upstream release, including whatever changes are necessary to work with
    the library when built with --no-deprecated, even though
    --no-deprecated is not enabled by default.

    Technically, the reverse dependencies are now ABI compatible across
    both versions - with and without the deprecated symbols. That cannot
    mean that the library itself can drop those deprecated symbols
    upstream without changing the SONAME. So the first upstream release of
    the library with all the deprecated symbols removed (not just disabled)
    needs to bump the SONAME, as does the Debian package.

    Just because all the reverse dependencies in Debian have migrated
    successfully, does not mean that upstream do not have to make a SONAME
    bump.

    --


    Neil Williams
    =============
    http://www.data-freedom.org/
    http://www.nosoftwarepatents.com/
    http://www.linux.codehelp.co.uk/


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjVM00ACgkQk7DVr6iX/QLiZgCfR5+LVCdNphot+v6mZp4UhpPN
    HYoAn0N8pxvZyhVeFWmwACIU2LXMcYrz
    =Bb9U
    -----END PGP SIGNATURE-----


  15. Re: Headsup: ncurses soname bump 5 to 6

    Julien Cristau writes:

    >> So the obvious solution seems to me then to build ncurses twice,
    >> providing both libncurses5 and libncurses6 packages. What point do I miss?
    >>

    > The crashes that will happen when both are loaded in a process's address
    > space.


    Which is the case when:

    - a library (libfoo0) is linked to libncurses5
    - a program links to both libfoo0 and libncurses5
    - the library is recompiled to link against libncurses6

    Can we avoid that case by enforcing such libraries to change its package
    name (libfoo0 -> libfoo0a) in order to force dependening programs to be
    recompiled?

    --
    Gruesse/greetings,
    Reinhard Tartler, KeyID 945348A4


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3