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, Raphael Hertzog wrote: > Library maintainers are supposed to maintain the *.symbols file. For > this, they have to create files "debian/ .symbols. " > (dpkg-gensymbols will try too fallback to "debian/symbols. ", > "debian/ ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Re: Dependencies on shared libs, take 2

  1. Re: Dependencies on shared libs, take 2

    On Mon, Jun 04, 2007, Raphael Hertzog wrote:
    > Library maintainers are supposed to maintain the *.symbols file. For
    > this, they have to create files "debian/.symbols."
    > (dpkg-gensymbols will try too fallback to "debian/symbols.",
    > "debian/.symbols" and "debian/symbols"). They are
    > required to provide the minimal version (as used in the dependency
    > generated) associated to each symbol.


    While this seemed sensible on my first read, I think it's a burden to
    effectively maintain multiple *.symbols.* files for multiple arches or
    packages (for example flavors of the same library) with only small
    differences between the lists.
    I was about to suggest adding a way to share such lists, for example
    an include mechanism, but all of this seems to be at the wrong level:
    I think dpkg-* tools should only be concerned about debian/symbols or
    DEBIAN/symbols, and leave handling of architecture / package specific
    overrides to higher level stacks such as debhelper.

    I suppose maintainers will resort to the same file generation tricks
    that they already use to share file lists, shlibs information or
    whatever, and CDBS will provide new hooks for overrides as well


    Quid of udebs? Are these affected by the changes?

    > Since symbol information is integrated in the package itself, a
    > "debdiff --controlfiles ALL" would directly show if a package
    > introduces new symbols or removes existing ones.


    That a cool feature by itself, it means I will be able to review symbol
    changes without resorting to custom scripts or manual diffs!

    --
    Loïc Minier


    --
    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, Loïc Minier wrote:
    > On Mon, Jun 04, 2007, Raphael Hertzog wrote:
    > > Library maintainers are supposed to maintain the *.symbols file. For
    > > this, they have to create files "debian/.symbols."
    > > (dpkg-gensymbols will try too fallback to "debian/symbols.",
    > > "debian/.symbols" and "debian/symbols"). They are
    > > required to provide the minimal version (as used in the dependency
    > > generated) associated to each symbol.

    >
    > While this seemed sensible on my first read, I think it's a burden to
    > effectively maintain multiple *.symbols.* files for multiple arches or
    > packages (for example flavors of the same library) with only small
    > differences between the lists.
    > I was about to suggest adding a way to share such lists, for example
    > an include mechanism, but all of this seems to be at the wrong level:
    > I think dpkg-* tools should only be concerned about debian/symbols or
    > DEBIAN/symbols, and leave handling of architecture / package specific
    > overrides to higher level stacks such as debhelper.


    While I agree on the burden, I don't think it's wise to rely on other
    tools to merge multiple informations in a single file which would then be
    given to dpkg-gensymbols.

    I want to first do archive-wide rebuilds and see how many packages have
    differences between arches and what's best to handle them.

    > Quid of udebs? Are these affected by the changes?


    No (or at least they shouldn't). The problem with udebs is multiple:
    1/ they are meant to be small, so we don't want to integrate symbols file
    in the .udeb
    2/ dpkg-shlibdeps does follow executable -> library -> package ->
    /var/lib/dpkg/info/.{shlibs,symbols} to find out the
    dependencies. However with udebs the step "library -> package" can't be
    done with "dpkg --search" (it's currently done this way by dpkg-shlibdeps).

    If those two problems are solved, then it can also be done for udebs of
    course.

    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

    On Mon, Jun 04, 2007, Raphael Hertzog wrote:
    > While I agree on the burden, I don't think it's wise to rely on other
    > tools to merge multiple informations in a single file which would then be
    > given to dpkg-gensymbols.


    Hmm, how is this different from the way *.shlibs files are handled
    currently?

    > I want to first do archive-wide rebuilds and see how many packages have
    > differences between arches and what's best to handle them.


    Good idea; gathering some data should help.

    --
    Loïc Minier


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

  4. Re: Dependencies on shared libs, take 2

    On Mon, 04 Jun 2007, Loïc Minier wrote:
    > On Mon, Jun 04, 2007, Raphael Hertzog wrote:
    > > While I agree on the burden, I don't think it's wise to rely on other
    > > tools to merge multiple informations in a single file which would then be
    > > given to dpkg-gensymbols.

    >
    > Hmm, how is this different from the way *.shlibs files are handled
    > currently?


    I don't see much similarity.

    - shlibs are not created by any dpkg-* tool, but symbols files are
    - dh_makeshlibs create shlibs file but without using any local file
    as input, all the input comes from the command line
    - dh_installdeb installs maintainer provided shlibs file but it doesn't
    use any dpkg-* tool to do that, it merely copies the file over

    For me the symbols files are coupled to dpkg-gensymbols and any
    manipulation is best done by this tool instead of letting other
    high-level tools chime in. I'll gladly add any required feature do
    dpkg-gensymbols directly.

    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

  5. Re: Dependencies on shared libs, take 2

    Le lundi 04 juin 2007 à 12:27 +0200, Raphael Hertzog a écrit :
    > 2/ dpkg-shlibdeps does follow executable -> library -> package ->
    > /var/lib/dpkg/info/.{shlibs,symbols} to find out the
    > dependencies. However with udebs the step "library -> package" can't be
    > done with "dpkg --search" (it's currently done this way by dpkg-shlibdeps).


    Why couldn't the package -> udeb mapping, which is currently done in
    the .shlibs file, be done in the .symbols file ?
    --
    .''`.
    : :' : 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)

    iD8DBQBGZFkSrSla4ddfhTMRAolsAKCgFycDu6Bd+3P5A5+Lii MuPrxIWgCfa5Am
    wUF0XbA+ojD+M8FcR3kJM/o=
    =wkon
    -----END PGP SIGNATURE-----


  6. Re: Dependencies on shared libs, take 2

    Le lundi 04 juin 2007 à 21:13 +0200, Raphael Hertzog a écrit :
    > We could create a .symbols-udeb however... we just need to scan the
    > udeb during build and put the resulting symbols file in the main library.
    > That wouldn't be too difficult to do. We can probably keep this as
    > extension for the future.


    Yes, this looks like a better way to implement this than the current
    mix.
    --
    .''`.
    : :' : 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)

    iD8DBQBGZGS8rSla4ddfhTMRAtTvAJ0UkjiJQpDmf3RPkruphX iZMe9CywCgncuT
    BhM0+sW7hW5gHVJ6lw/RpBo=
    =SXa4
    -----END PGP SIGNATURE-----


  7. Re: Dependencies on shared libs, take 2

    On Mon, 04 Jun 2007, Josselin Mouette wrote:
    > Le lundi 04 juin 2007 à 12:27 +0200, Raphael Hertzog a écrit :
    > > 2/ dpkg-shlibdeps does follow executable -> library -> package ->
    > > /var/lib/dpkg/info/.{shlibs,symbols} to find out the
    > > dependencies. However with udebs the step "library -> package" can't be
    > > done with "dpkg --search" (it's currently done this way by dpkg-shlibdeps).

    >
    > Why couldn't the package -> udeb mapping, which is currently done in
    > the .shlibs file, be done in the .symbols file ?


    Hum, right. It could. I'm not sure I like it though.

    Having to maintain one set of symbols is complicated enough that having
    two set of symbols in the same file is probably not desirable. We could
    decide to add a new field containing the udeb name (if there's any) but
    then udeb are udebs precisely because they are minimal and probably
    compiled with different options than the main lib so that sharing the set
    of symbols is probably not the good choice.

    We could create a .symbols-udeb however... we just need to scan the
    udeb during build and put the resulting symbols file in the main library.
    That wouldn't be too difficult to do. We can probably keep this as
    extension for the future.

    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

  8. Re: Dependencies on shared libs, take 2

    Loïc Minier writes:
    > On Mon, Jun 04, 2007, Raphael Hertzog wrote:
    >> Library maintainers are supposed to maintain the *.symbols file. For
    >> this, they have to create files "debian/.symbols."
    >> (dpkg-gensymbols will try too fallback to "debian/symbols.",
    >> "debian/.symbols" and "debian/symbols"). They are
    >> required to provide the minimal version (as used in the dependency
    >> generated) associated to each symbol.

    > While this seemed sensible on my first read, I think it's a burden to
    > effectively maintain multiple *.symbols.* files for multiple arches or
    > packages (for example flavors of the same library) with only small
    > differences between the lists.


    Showers need to be good for something, so I thought about this today in
    the shower and wondered why the arch files couldn't be treated as simple
    override files. I expect that most libraries keep the same version data
    for (almost) all archs in sync, so it seems to be sensible to simply use
    a debian/$package.symbols file and only override the information for the
    few needed symbols in a debian/$package.symbols.$arch file.

    The current codebase would only need a few changes (loading
    debian/symbols, then loading debian/symbols.$arch into the same hash).

    This doesn't reduce the work needed for various flavours of the same
    lib, so an include statement would perhaps still be a good idea. Or
    simply preprocess all files with cpp :-)

    Marc
    --
    Fachbegriffe der Informatik - Einfach erklärt
    70: It is essential that implementations by different vendors interoperate.
    Unsere proprietären Basteleien dokumentieren wir gar nicht erst.
    (Sven Türpe)

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

    iD8DBQFGZWnHmO5zOp3h7rERAuSjAJ9b9NSEeIA7mZIIlPB7nz ljz3M0sQCfS39N
    n2Nl+Z2acvRHagFXcxrnDtI=
    =i4GC
    -----END PGP SIGNATURE-----

+ Reply to Thread