Early adopters of symbol based dependencies needed - Debian

This is a discussion on Early adopters of symbol based dependencies needed - Debian ; On Wed, 21 Nov 2007, Mike Hommey wrote: > 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 30 of 30

Thread: Early adopters of symbol based dependencies needed

  1. Re: Early adopters of symbol based dependencies needed

    On Wed, 21 Nov 2007, Mike Hommey wrote:
    > 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.


    In particular for C++ packages. For C packages, the size impact is quite
    limited compared to the size of the respective libraries.

    I didn't implement this until now because all files in control.tar.gz have
    always been plain text files and I'm not sure I want to change this. Other
    opinions are welcome.

    > - 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.


    Is fixed in git as already noted.

    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

    On Wed, 21 Nov 2007, Russ Allbery wrote:
    > 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.


    Aren't they supposed to have a prototype to avoid such behaviour?

    I mean exists should behave like myprint2 in the example below:
    sub myprint {
    print $_[0] . "\n";
    }

    sub myprint2 ($) {
    print $_[0] . "\n";
    }

    %a = ('a' => 'this is a');
    myprint $a{a} && exists $a{a};
    myprint2 $a{a} && exists $a{a};

    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: Early adopters of symbol based dependencies needed

    Raphael Hertzog writes:

    > Aren't they supposed to have a prototype to avoid such behaviour?


    Ah, indeed. I had forgotten about that. You're entirely correct.

    --
    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

  4. Re: Early adopters of symbol based dependencies needed

    * Russ Allbery:

    >> 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?


    Performance penalty of PIC code due to register pressure, I guess.


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

  5. Re: Early adopters of symbol based dependencies needed

    This one time, at band camp, Florian Weimer said:
    > * Russ Allbery:
    >
    > >> 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?

    >
    > Performance penalty of PIC code due to register pressure, I guess.


    Is this a significant enough issue to live with the other issues this
    creates? I honestly don't know. It 'feels' like the right way to have
    perl compiled would be the same on all architectures, /usr/bin/perl
    linked to libperl, and the binary modules linked to libperl. I
    understand this may be a problem, I just don't know how big of one it
    would be.
    --
    -----------------------------------------------------------------
    | ,''`. Stephen Gran |
    | : :' : sgran@debian.org |
    | `. `' Debian user, admin, and developer |
    | `- http://www.debian.org |
    -----------------------------------------------------------------

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

    iD8DBQFHRDBSSYIMHOpZA44RApmFAKCG/5L0PQaHD/1pIgaruuCLDBkGiQCgsICM
    g+wZ2G+3lasvr6jWpNhXY4w=
    =uhn2
    -----END PGP SIGNATURE-----


  6. Re: Early adopters of symbol based dependencies needed

    Florian Weimer wrote:
    > * Russ Allbery:
    >
    > >> 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?

    >
    > Performance penalty of PIC code due to register pressure, I guess.


    I seem to remember it was a threading issue, but I didn't manage to
    track down an explanation.

    --
    see shy jo

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

    iD8DBQFHRFaud8HHehbQuO8RAjVOAJ96NorMJy+lnBJtogJnfJ fTojN/GwCeMY1/
    TKDXGyQPYP2RKfNNwHYC7PU=
    =VeyB
    -----END PGP SIGNATURE-----


  7. Re: Early adopters of symbol based dependencies needed

    Raphael Hertzog wrote:
    > 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.


    I thought that part of the point of the symbols files was to get more
    accurate dependency information. If unversioned -V is used, dependencies
    will remain overly tight.

    --
    see shy jo

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

    iD8DBQFHRFZnd8HHehbQuO8RAgi8AJ9QvuvOP4Dm3sAr+QXXeG qjMr/eFACg3f4R
    NDBvQyIHh6GKfvqGrmH41XE=
    =2B7T
    -----END PGP SIGNATURE-----


  8. Re: Early adopters of symbol based dependencies needed

    Raphael Hertzog wrote:
    > And shlibs files are ignored if dpkg-shlibdeps is able to find
    > symbols files.


    Ah, that wasn't clear, I must have missed that in the documentation.

    --
    see shy jo

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

    iD8DBQFHRLNvd8HHehbQuO8RAgrIAKC4xzRguH79tCfthJgiXi +GMWAexQCeKOcA
    Hcb3Sgx339W0yWUyA+Ge/M8=
    =Gw89
    -----END PGP SIGNATURE-----


  9. Re: Early adopters of symbol based dependencies needed

    * Joey Hess:

    >> Performance penalty of PIC code due to register pressure, I guess.

    >
    > I seem to remember it was a threading issue, but I didn't manage to
    > track down an explanation.


    Well, Perl should use __thread anyway, so it's unlikely that the issue
    is still present.


    --
    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

    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.


    I think dpkg-shlibdeps uses the symbols files if they're present, and
    the shlibs files if they're not. So I would keep maintaining the -V
    like you do now. But at some point I'd like to remove it.


    Kurt


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