Early adopters of symbol based dependencies needed - Debian

This is a discussion on Early adopters of symbol based dependencies needed - Debian ; Hello, since the upload of dpkg 1.14.8 to unstable, it's now possible for library packages to generate "symbols" control files that will be used by other packages to get more accurate (and less strict) dependencies. As this is a far ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 30

Thread: Early adopters of symbol based dependencies needed

  1. Early adopters of symbol based dependencies needed

    Hello,

    since the upload of dpkg 1.14.8 to unstable, it's now possible for
    library packages to generate "symbols" control files that will be used by
    other packages to get more accurate (and less strict) dependencies.

    As this is a far reaching change, I'd like some skilled maintainers to try
    it out "for real" and help me flesh out some generic guidelines so that when
    we start using it on more packages, we do it right from the first time.

    The wiki page http://wiki.debian.org/UsingSymbolsFiles will be used to
    collect various remarks and prepare some useful documentation that will
    be later spread to maintainers through d-d-a (and maybe merged back in
    some dpkg manual page).

    Integrated documentation
    ------------------------
    The existing documentation is integrated in various dpkg manual pages:
    - dpkg-gensymbols(1)
    - dpkg-shlibdeps(1)
    - deb-symbols(5)

    Debhelper support
    -----------------
    With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
    finds debian/.symbols (or debian/.symbols.). So
    for packages using debhelper, the only thing to do is to drop the right
    symbol file(s) at the right place and add build-depends on dpkg-dev (>= 1.14.9)
    and debhelper (>= 5.0.61).

    Some pre-generated symbols files can be downloaded on
    http://qa.debian.org/cgi-bin/mole/seedsymbols/

    Beware, those files have been auto-generated and should be verified by the
    maintainer (check that the version are correct, I just fixed a bug where
    epoch were lost). Adapt the dependency field if needed, verify if
    the dependency associated to some symbols have to be bumped (see below),
    etc.

    Warnings
    --------
    1/ The symbols files associate a minimum version to each symbol that an
    application might be using. By default, that version is calculated as the
    first version where the symbol appeared. This is the best approximation
    that we can automatically generate. Please note however that the function
    might have been extended in backwards-compatible ways which would still
    deserve an increment of the minimal required version (for example when new
    values are allowed in existing parameters which were previously not
    accepted). To detect such problems one must have a good knowledge of the
    API of the library.

    It would be great to have an exhaustive list of similar cases that
    maintainers should be watching for in upstream ChangeLogs.

    2/ Watch out if adding support of symbols files break unofficial
    architectures (like armel or kfreebsd-i386/amd64). Because the
    pre-generated files only take into account the current list of official
    architectures, so you might not be aware of some differences in the symbol
    set. You can check the build log of your package on unofficial
    architectures on http://experimental.debian.net/
    (http://experimental.debian.net/build.php?pkg=glibc for example).

    Feel free to make suggestions to avoid such breakage when possible. See
    also discussions in http://bugs.debian.org/452022 on that topic.

    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

  2. Re: Early adopters of symbol based dependencies needed

    Le mardi 20 novembre 2007 à 16:22 +0100, Raphael Hertzog a écrit :
    > 2/ Watch out if adding support of symbols files break unofficial
    > architectures (like armel or kfreebsd-i386/amd64). Because the
    > pre-generated files only take into account the current list of official
    > architectures, so you might not be aware of some differences in the symbol
    > set. You can check the build log of your package on unofficial
    > architectures on http://experimental.debian.net/
    > (http://experimental.debian.net/build.php?pkg=glibc for example).
    >
    > Feel free to make suggestions to avoid such breakage when possible. See
    > also discussions in http://bugs.debian.org/452022 on that topic.


    A guaranteed way to trigger such issues is to export all functions built
    in the library as symbols, which is unfortunately the default behavior.
    This way the list will change if you change the optimization parameters
    or on unofficial architectures.

    If upstream doesn't support this, the simplest way to restrict the list
    of functions is to use a version script ; this script can be written
    manually or automatically generated by libtool with the -export-symbols
    or -export-symbols-regex options.

    --
    .''`.
    : :' : 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)

    iD8DBQBHQwLPrSla4ddfhTMRAj7kAJ9c3tD+cK/pNOvx7qVt9iHAvF5akgCfUQGT
    pNe/R7TobAyRBpNdkeIll4Q=
    =5Yio
    -----END PGP SIGNATURE-----


  3. Re: Early adopters of symbol based dependencies needed

    So FWIW, I have aalib using a symbol file, it's what I used to test the
    debhelper modifications. Haven't uploaded it yet because it will have to
    build-depend on the recent dpkg bugfix. Also because dpkg-shlibdeps is
    now smart enough to complain about some unnecessary linkages to things
    like libm and libslang in libaa-bin, and I haven't sat down and figured
    out if I should really remove those direct linkages (probably).

    I also thought about using symbol files for the not very shared
    libraries in the fbreader source package, but there's C++ symbol
    mangling going on, so I think I can't.

    > 1/ The symbols files associate a minimum version to each symbol that an
    > application might be using. By default, that version is calculated as the
    > first version where the symbol appeared.


    Assuming the first version of the symbol is at least in oldstable. :-)

    --
    see shy jo

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

    iD8DBQFHQxvnd8HHehbQuO8RApOuAKCkufzxyM/zWbVabetR/74BrB5xagCgp0K5
    JyOxdBw5VsvfpMHoMNIHO74=
    =zlOY
    -----END PGP SIGNATURE-----


  4. Re: Early adopters of symbol based dependencies needed

    Raphael Hertzog wrote:
    > With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
    > finds debian/.symbols (or debian/.symbols.). So
    > for packages using debhelper, the only thing to do is to drop the right
    > symbol file(s) at the right place and add build-depends on dpkg-dev (>=1.14.9)
    > and debhelper (>= 5.0.61).


    I suppose you'd also want to stop passing -V to dh_makeshlibs,
    since the symbol versioning should take care of setting the version.
    -V without any parameters is evil anyway.

    Although, what happens if a package is built against the library on
    a buildd that doesn't have the new dpkg-dev yet? It would generate a
    wrong unversioned dependency in this case.

    --
    see shy jo

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

    iD8DBQFHQyVxd8HHehbQuO8RAotvAKDMwWG6MTbBmB55oTKwEd Imq6V/eACffAo+
    OLhWNyScegxkhSAxPfO+pZ8=
    =Jkux
    -----END PGP SIGNATURE-----


  5. Re: Early adopters of symbol based dependencies needed

    On Tue, 20 Nov 2007, Joey Hess wrote:
    > I also thought about using symbol files for the not very shared
    > libraries in the fbreader source package, but there's C++ symbol
    > mangling going on, so I think I can't.


    You can, but it generally means having to handle arch-specific symbols
    files because symbol mangling vary from arch to arch (at least between
    32bit and 64bit arch).

    > > 1/ The symbols files associate a minimum version to each symbol that an
    > > application might be using. By default, that version is calculated as the
    > > first version where the symbol appeared.

    >
    > Assuming the first version of the symbol is at least in oldstable. :-)


    In fact, I scanned stable, testing and unstable to create the initial
    files. So, oldstable has not been considered. And now the files are kept
    up-to-date with all unstable uploads (experimental ones are not
    considered).

    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

  6. Re: Early adopters of symbol based dependencies needed

    On Tue, Nov 20, 2007 at 01:20:33PM -0500, Joey Hess wrote:
    > Raphael Hertzog wrote:
    > > With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
    > > finds debian/.symbols (or debian/.symbols.). So
    > > for packages using debhelper, the only thing to do is to drop the right
    > > symbol file(s) at the right place and add build-depends on dpkg-dev (>= 1.14.9)
    > > and debhelper (>= 5.0.61).

    >
    > I suppose you'd also want to stop passing -V to dh_makeshlibs,
    > since the symbol versioning should take care of setting the version.
    > -V without any parameters is evil anyway.
    >
    > Although, what happens if a package is built against the library on
    > a buildd that doesn't have the new dpkg-dev yet? It would generate a
    > wrong unversioned dependency in this case.


    Do buildds have special rules for build dependencies on dpkg-dev ? O_o

    Mike


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

  7. Re: Early adopters of symbol based dependencies needed

    On Tue, Nov 20, 2007 at 04:22:56PM +0100, Raphael Hertzog wrote:
    > Some pre-generated symbols files can be downloaded on
    > http://qa.debian.org/cgi-bin/mole/seedsymbols/
    >
    > Beware, those files have been auto-generated and should be verified by the
    > maintainer (check that the version are correct, I just fixed a bug where
    > epoch were lost). Adapt the dependency field if needed, verify if
    > the dependency associated to some symbols have to be bumped (see below),
    > etc.


    Are the @Base in these files really necessary ? I mean, most packages
    have no symbol versioning and thus use the "Base" version. Does it work
    without it being explicitly put ? If not, don't you think it would make
    sense ?

    Mike


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

  8. Re: Early adopters of symbol based dependencies needed

    Raphael Hertzog writes:

    > Hello,
    >
    > since the upload of dpkg 1.14.8 to unstable, it's now possible for
    > library packages to generate "symbols" control files that will be used
    > by other packages to get more accurate (and less strict) dependencies.
    >
    > As this is a far reaching change, I'd like some skilled maintainers to
    > try it out "for real" and help me flesh out some generic guidelines so
    > that when we start using it on more packages, we do it right from the
    > first time.
    >
    > The wiki page http://wiki.debian.org/UsingSymbolsFiles will be used to
    > collect various remarks and prepare some useful documentation that will
    > be later spread to maintainers through d-d-a (and maybe merged back in
    > some dpkg manual page).


    Hi Raphael,

    I'll give this a try for libremctl1. It seems like a good candidate for a
    test of something that's still fairly experimental: there are currently no
    reverse-depends in Debian, it's a small library, it's already using symbol
    versioning, and I'm also upstream.

    > Some pre-generated symbols files can be downloaded on
    > http://qa.debian.org/cgi-bin/mole/seedsymbols/


    This is awesome. Thank you very much for doing this. It makes it much
    easier to start.

    --
    Russ Allbery (rra@debian.org)


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

  9. Re: Early adopters of symbol based dependencies needed

    On Tue, Nov 20, 2007 at 10:05:41PM +0100, Mike Hommey wrote:
    > On Tue, Nov 20, 2007 at 01:20:33PM -0500, Joey Hess wrote:
    > > Raphael Hertzog wrote:
    > > > With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
    > > > finds debian/.symbols (or debian/.symbols.). So
    > > > for packages using debhelper, the only thing to do is to drop the right
    > > > symbol file(s) at the right place and add build-depends on dpkg-dev (>= 1.14.9)
    > > > and debhelper (>= 5.0.61).

    > >
    > > I suppose you'd also want to stop passing -V to dh_makeshlibs,
    > > since the symbol versioning should take care of setting the version.
    > > -V without any parameters is evil anyway.
    > >
    > > Although, what happens if a package is built against the library on
    > > a buildd that doesn't have the new dpkg-dev yet? It would generate a
    > > wrong unversioned dependency in this case.

    >
    > Do buildds have special rules for build dependencies on dpkg-dev ? O_o


    Oh now I understood. Well, I guess the -V should still be used...

    Mike


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

  10. Re: Early adopters of symbol based dependencies needed

    Raphael Hertzog writes:

    > since the upload of dpkg 1.14.8 to unstable, it's now possible for
    > library packages to generate "symbols" control files that will be used
    > by other packages to get more accurate (and less strict) dependencies.


    > As this is a far reaching change, I'd like some skilled maintainers to
    > try it out "for real" and help me flesh out some generic guidelines so
    > that when we start using it on more packages, we do it right from the
    > first time.


    A couple of early points of feedback, which I'll send here since I think
    they'd benefit from broader discussion:

    * The seed symbols files include the full Debian package version for when
    the symbol was first available. For example, for libremctl1, all of
    the symbols are marked as first available in 2.10-1.

    This causes a problem for backports. A backport of 2.10-1 would
    provide all the same symbols, but would have a version of
    2.10-1~bpo40+1 or something similar. This would be less than the
    version advertised by the symbols file, which means that the backport
    wouldn't satisfy the regular package dependency even though it would
    work. This will mean that symbols files will have to be adjusted when
    building backported packages, unless I miss some subtlety.

    I always use dependencies like >= 2.10 in shlibs files rather than the
    more specific 2.10-1 because of this problem. I'm not sure if that's
    the right general solution, but people who start from the seed files
    should at least consider removing the Debian revision in cases like
    this to make backporting easier.

    * The new warnings from the dpkg-* tools warn about any binary Perl
    module because all binary Perl modules use symbols from Perl itself but
    traditionally aren't linked directly against libperl. (There was some
    reason for this that I don't recall off-hand.) Should these warnings
    just be ignored? Suppressed in some way? Should binary Perl modules
    link against libperl? I haven't worked through the implications in my
    head yet.

    --
    Russ Allbery (rra@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: Early adopters of symbol based dependencies needed

    Stephen Gran writes:
    > This one time, at band camp, Russ Allbery said:


    >> * The new warnings from the dpkg-* tools warn about any binary Perl
    >> module because all binary Perl modules use symbols from Perl itself but
    >> traditionally aren't linked directly against libperl. (There was some
    >> reason for this that I don't recall off-hand.) Should these warnings
    >> just be ignored? Suppressed in some way? Should binary Perl modules
    >> link against libperl? I haven't worked through the implications in my
    >> head yet.


    > See #416266 for an example of why it would be nice if they did. Linking
    > the binary perl modules to libperl does make this problem go away, but
    > I've been waiting to push it over to the perl folks until we have
    > something resembling patches.


    Oh, right, that's the problem. /usr/bin/perl doesn't use libperl itself
    and instead just exports the same symbols to any modules it loads. So if
    the module is linked with libperl, when the module is loaded by the Perl
    interpretor, it loads libperl into the same namespace, the Perl
    interpretor and libperl both define the same symbols, and the world
    explodes.

    --
    Russ Allbery (rra@debian.org)


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

  12. Re: Early adopters of symbol based dependencies needed

    This one time, at band camp, Russ Allbery said:
    > * The new warnings from the dpkg-* tools warn about any binary Perl
    > module because all binary Perl modules use symbols from Perl itself but
    > traditionally aren't linked directly against libperl. (There was some
    > reason for this that I don't recall off-hand.) Should these warnings
    > just be ignored? Suppressed in some way? Should binary Perl modules
    > link against libperl? I haven't worked through the implications in my
    > head yet.


    See #416266 for an example of why it would be nice if they did. Linking
    the binary perl modules to libperl does make this problem go away, but
    I've been waiting to push it over to the perl folks until we have
    something resembling patches.
    --
    -----------------------------------------------------------------
    | ,''`. Stephen Gran |
    | : :' : sgran@debian.org |
    | `. `' Debian user, admin, and developer |
    | `- http://www.debian.org |
    -----------------------------------------------------------------

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

    iD8DBQFHQ2JoSYIMHOpZA44RAowgAJ4nK2VTBKth79hlS4JDfJ +ootsaJACgorjY
    RVKiDKQRazeNuryqBMoJIA8=
    =PGPW
    -----END PGP SIGNATURE-----


  13. Re: Early adopters of symbol based dependencies needed

    This one time, at band camp, Russ Allbery said:
    > Stephen Gran writes:
    > > This one time, at band camp, Russ Allbery said:

    >
    > >> * The new warnings from the dpkg-* tools warn about any binary Perl
    > >> module because all binary Perl modules use symbols from Perl itselfbut
    > >> traditionally aren't linked directly against libperl. (There was some
    > >> reason for this that I don't recall off-hand.) Should these warnings
    > >> just be ignored? Suppressed in some way? Should binary Perl modules
    > >> link against libperl? I haven't worked through the implications inmy
    > >> head yet.

    >
    > > See #416266 for an example of why it would be nice if they did. Linking
    > > the binary perl modules to libperl does make this problem go away, but
    > > I've been waiting to push it over to the perl folks until we have
    > > something resembling patches.

    >
    > Oh, right, that's the problem. /usr/bin/perl doesn't use libperl itself
    > and instead just exports the same symbols to any modules it loads. So if
    > the module is linked with libperl, when the module is loaded by the Perl
    > interpretor, it loads libperl into the same namespace, the Perl
    > interpretor and libperl both define the same symbols, and the world
    > explodes.


    As I understand it, this is only the case on i386 - on other arches,
    /usr/bin/perl links to libperl, although the modules don't.
    --
    -----------------------------------------------------------------
    | ,''`. Stephen Gran |
    | : :' : sgran@debian.org |
    | `. `' Debian user, admin, and developer |
    | `- http://www.debian.org |
    -----------------------------------------------------------------

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

    iD8DBQFHQ2oRSYIMHOpZA44RAlt0AKC56uKm1mBE7RoeF5Xmt5 tIEpDG2QCeLtEU
    a/gXO6Ytm6Jypw9wst2DZ4I=
    =8jUq
    -----END PGP SIGNATURE-----


  14. Re: Early adopters of symbol based dependencies needed

    Raphael Hertzog writes:

    > Integrated documentation
    > ------------------------
    > The existing documentation is integrated in various dpkg manual pages:
    > - dpkg-gensymbols(1)
    > - dpkg-shlibdeps(1)
    > - deb-symbols(5)


    In case anyone would like to do some minor coding around this, I'd love to
    have a lintian check for proper formatting of the symbols file (and
    possibly also to check that the proper dpkg-dev and debhelper dependencies
    are present if a *.symbols file is found in the debian directory).

    I'll probably end up writing one myself eventually, but I don't have much
    time to work on it at the moment.

    --
    Russ Allbery (rra@debian.org)


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

  15. Re: Early adopters of symbol based dependencies needed

    Stephen Gran writes:
    > This one time, at band camp, Russ Allbery said:


    >> Oh, right, that's the problem. /usr/bin/perl doesn't use libperl
    >> itself and instead just exports the same symbols to any modules it
    >> loads. So if the module is linked with libperl, when the module is
    >> loaded by the Perl interpretor, it loads libperl into the same
    >> namespace, the Perl interpretor and libperl both define the same
    >> symbols, and the world explodes.


    > As I understand it, this is only the case on i386 - on other arches,
    > /usr/bin/perl links to libperl, although the modules don't.


    ....indeed. That's bizarre. Why is i386 different than all the other
    platforms?

    If /usr/bin/perl linked with libperl on every platform, we should be able
    to safely change modules to link with libperl without creating any
    problems. But right now, that change would probably break things on i386
    in obscure and bizarre ways.

    (One of the standard nasty problems with multiple copies of the same
    symbols is that different versions of a function get called at different
    times and, when they use any static data, that static data is different
    between the different instances. It creates incredibly weird problems
    that are horrible to debug.)

    --
    Russ Allbery (rra@debian.org)


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

  16. Re: Early adopters of symbol based dependencies needed

    On Tue, 20 Nov 2007, Joey Hess wrote:
    > Raphael Hertzog wrote:
    > > With debhelper 5.0.61, dh_makeshlibs will also call dpkg-gensymbols if it
    > > finds debian/.symbols (or debian/.symbols.). So
    > > for packages using debhelper, the only thing to do is to drop the right
    > > symbol file(s) at the right place and add build-depends on dpkg-dev (>= 1.14.9)
    > > and debhelper (>= 5.0.61).

    >
    > I suppose you'd also want to stop passing -V to dh_makeshlibs,
    > since the symbol versioning should take care of setting the version.
    > -V without any parameters is evil anyway.
    >
    > Although, what happens if a package is built against the library on
    > a buildd that doesn't have the new dpkg-dev yet? It would generate a
    > wrong unversioned dependency in this case.


    Given that shlibs are still used as fallback, I don't see a reason to
    remove -V, in particular given that unofficial archs might not have
    symbols files when they are arch-specific and when something specific
    needs to be done to add support for a new arch.

    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

  17. Re: Early adopters of symbol based dependencies needed

    On Tue, 20 Nov 2007, Mike Hommey wrote:
    > Are the @Base in these files really necessary ?


    With the current code, IIRC yes.

    > I mean, most packages have no symbol versioning and thus use the "Base"
    > version. Does it work without it being explicitly put ?


    Probably not.

    > If not, don't you think it would make sense ?


    Maybe, someone else already made the remark, but I like when things are
    explicit.

    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

  18. Re: Early adopters of symbol based dependencies needed

    On Tue, 20 Nov 2007, Russ Allbery wrote:
    > I always use dependencies like >= 2.10 in shlibs files rather than the
    > more specific 2.10-1 because of this problem. I'm not sure if that's
    > the right general solution, but people who start from the seed files
    > should at least consider removing the Debian revision in cases like
    > this to make backporting easier.


    Good point. Added to the wiki page.

    > * The new warnings from the dpkg-* tools warn about any binary Perl
    > module because all binary Perl modules use symbols from Perl itself but
    > traditionally aren't linked directly against libperl. (There was some
    > reason for this that I don't recall off-hand.) Should these warnings
    > just be ignored? Suppressed in some way? Should binary Perl modules
    > link against libperl? I haven't worked through the implications in my
    > head yet.


    This is not normal.
    http://git.debian.org/?p=dpkg/dpkg.g...58e3165253eb58

    This change was precisely meant to silence those warnings. But it looks
    like this line is problematic:
    return exists $self->{flags}{DYNAMIC} and $self->{flags}{DYNAMIC}
    and exists $self->{SONAME} and $self->{SONAME};

    It's parsed as:
    (return exists $self->{flags}{DYNAMIC}) and ...

    Replacing "and" by "&&" fixes the problem. It's weird because I'm pretty sure it
    worked before and I tested it. Anyway, it's fixed in git and will be in the next
    dpkg version.

    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

  19. Re: Early adopters of symbol based dependencies needed

    On Tue, Nov 20, 2007 at 04:22:56PM +0100, Raphael Hertzog wrote:
    > Hello,
    >
    > since the upload of dpkg 1.14.8 to unstable, it's now possible for
    > library packages to generate "symbols" control files that will be used by
    > other packages to get more accurate (and less strict) dependencies.
    >
    > As this is a far reaching change, I'd like some skilled maintainers to try
    > it out "for real" and help me flesh out some generic guidelines so that when
    > we start using it on more packages, we do it right from the first time.
    >
    > The wiki page http://wiki.debian.org/UsingSymbolsFiles will be used to
    > collect various remarks and prepare some useful documentation that will
    > be later spread to maintainers through d-d-a (and maybe merged back in
    > some dpkg manual page).


    FWIW, I'm testing this on libxml2. I'd have some remarks:
    - The .symbols file in /var/lib/dpkg/info is bigger than all the other
    maintainer files there for libxml2. If a significant amount of packages
    implement this, it can start to make a difference. It might be nice to
    support a gzipped format.
    - Python modules have the same problem as perl modules: the interpreter
    doesn't link against the library, so they can't either. That makes a
    whole bunch of warnings for each symbol not found... I'm not sure what
    should be done for that.

    Mike


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

  20. Re: Early adopters of symbol based dependencies needed

    Raphael Hertzog writes:

    > This change was precisely meant to silence those warnings. But it looks
    > like this line is problematic:
    > return exists $self->{flags}{DYNAMIC} and $self->{flags}{DYNAMIC}
    > and exists $self->{SONAME} and $self->{SONAME};
    >
    > It's parsed as:
    > (return exists $self->{flags}{DYNAMIC}) and ...
    >
    > Replacing "and" by "&&" fixes the problem. It's weird because I'm pretty
    > sure it worked before and I tested it. Anyway, it's fixed in git and
    > will be in the next dpkg version.


    Be careful about && because you can get the opposite problem.

    exists $self->{flags}{DYNAMIC && $self->{flags}{DYNAMIC}

    will be parsed as

    exists ($self->{flags}{DYNAMIC && $self->{flags}{DYNAMIC})

    It's often good style to always use parens with the argument to defined or
    exists because they're most often the functions that get bitten by this.

    --
    Russ Allbery (rra@debian.org)


    --
    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 1 of 2 1 2 LastLast