Re: Dependencies on shared libs, take 2 - Debian

This is a discussion on Re: Dependencies on shared libs, take 2 - Debian ; On Mon, Jun 04, 2007 at 10:54:30AM +0200, Raphael Hertzog wrote: > Library maintainers who want to avoid any mistakes can use the "-c" option > (for compare) which will make the compilation fail if the generated > symbols file ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Dependencies on shared libs, take 2

  1. Re: Dependencies on shared libs, take 2

    On Mon, Jun 04, 2007 at 10:54:30AM +0200, Raphael Hertzog wrote:
    > Library maintainers who want to avoid any mistakes can use the "-c" option
    > (for compare) which will make the compilation fail if the generated
    > symbols file differ from the maintainer supplied file. In that case, the
    > build log contains a diff between the two symbols files and he can analyze
    > the differences (and update his file if necessary).


    I think this should be the default behaviour.

    Mike


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

  2. Re: Dependencies on shared libs, take 2

    On Mon, 04 Jun 2007, Mike Hommey wrote:
    > On Mon, Jun 04, 2007 at 10:54:30AM +0200, Raphael Hertzog wrote:
    > > Library maintainers who want to avoid any mistakes can use the "-c" option
    > > (for compare) which will make the compilation fail if the generated
    > > symbols file differ from the maintainer supplied file. In that case, the
    > > build log contains a diff between the two symbols files and he can analyze
    > > the differences (and update his file if necessary).

    >
    > I think this should be the default behaviour.


    Well, the default behaviour that I intended to use is somewhat different
    and more suited to small libraries maybe:

    - the maintainer runs a script 'update-symbols' which downloads the latest
    symbols files for all arches in debian/ from a central server which
    extracts the symbols file from the last-built package.
    - the maintainer builds the new upstream package and the new symbol
    information is auto-merged in the generated symbols file
    - go back to first step for the next version

    This scheme allows to simply follow the history of the package without
    complicating too much the life of the maintainer.

    Furthermore non-versioned libraries export many private functions which
    can appear and disappear, and it shouldn't necessarily fail because of
    that. So this option is probably well suited for versioned libraries but
    too much hassle for non-versioned ones.

    Cheers,
    --
    Raphaël Hertzog

    Premier livre français sur Debian GNU/Linux :
    http://www.ouaza.com/livre/admin-debian/


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

  3. Re: Dependencies on shared libs, take 2

    Le lundi 04 juin 2007 à 11:25 +0200, Raphael Hertzog a écrit :
    > On Mon, 04 Jun 2007, Mike Hommey wrote:
    > > On Mon, Jun 04, 2007 at 10:54:30AM +0200, Raphael Hertzog wrote:
    > > > Library maintainers who want to avoid any mistakes can use the "-c" option
    > > > (for compare) which will make the compilation fail if the generated
    > > > symbols file differ from the maintainer supplied file. In that case, the
    > > > build log contains a diff between the two symbols files and he can analyze
    > > > the differences (and update his file if necessary).

    > >
    > > I think this should be the default behaviour.

    >
    > Well, the default behaviour that I intended to use is somewhat different
    > and more suited to small libraries maybe:
    >
    > - the maintainer runs a script 'update-symbols' which downloads the latest
    > symbols files for all arches in debian/ from a central server which
    > extracts the symbols file from the last-built package.
    > - the maintainer builds the new upstream package and the new symbol
    > information is auto-merged in the generated symbols file
    > - go back to first step for the next version


    I second Mike's request. It is important that this becomes the default
    behavior, so that libraries fail to build on other architectures, where
    the symbol list can be different.

    > This scheme allows to simply follow the history of the package without
    > complicating too much the life of the maintainer.
    >
    > Furthermore non-versioned libraries export many private functions which
    > can appear and disappear, and it shouldn't necessarily fail because of
    > that. So this option is probably well suited for versioned libraries but
    > too much hassle for non-versioned ones.


    It seems normal to update the file manually when the library switches
    some symbols to not be exported.

    Cheers,
    --
    .''`.
    : :' : 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.6 (GNU/Linux)

    iD8DBQBGZFh0rSla4ddfhTMRAucUAKDfa7hwCqQfIpLLhY3df4 7DqwkbKQCeMICQ
    8JIs8NVhTZxAe3h/N0zaobY=
    =hEa4
    -----END PGP SIGNATURE-----


+ Reply to Thread