Skip to content
Snippets Groups Projects

debian packaging: dropping patches and other improvements

    • Closed Issue created by Tomas Krizek @tkrizek

    The following discussions from !502 (merged) should be addressed:

    • @pspacek started a discussion: (+1 comment)

      Oh, I wonder whether we really need to have separate package with the library. I would rather not promote it as a separate library because we do not even try to keep its API stable (at least now).

    • @pspacek started a discussion: (+1 comment)

      Urgh, what about simpler rm ...root.hints somewhere after install call to make install? Solution with patch is bound to break more often.

    • @pspacek started a discussion: (+1 comment)

      I would prefer a patch which does not change the text above and just adds sentence about automatic update in Debian.

    2 of 3 checklist items completed · Edited
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items

    0
    Show labels

    No child items are currently assigned. Use child items to break down this issue into smaller parts.

      3

      When these merge requests are accepted, this issue will be closed automatically.

      Activity

      • Tomas Krizek mentioned in merge request !502 (merged)

        mentioned in merge request !502 (merged)

      • Tomas Krizek
        Tomas Krizek @tkrizek ·
        Author Owner

        Oh, I wonder whether we really need to have separate package with the library. I would rather not promote it as a separate library because we do not even try to keep its API stable (at least now).

        Promoting libkres as a shared library in Debian means we have to provide a symbols file, which has to be kept up to date with the library's symbols and any changes to them. If we didn't provide it as a shared library in a separate package, we could get rid of this file [1], which would make packaging for debian easier.

        AFAIK there are no debian packages (other than knot-resolver itself) than would depend on libkres. However, I'm not sure what would be the impact on things like modules if we didn't provide libkres as a shared library in a separate package.

        I'm neither an expert in debian packaging, nor in the way we (or others) use the libkres library, so I'd like to hear some other opinions on whether we could stop providing libkres as a shared library in debian and whether it's a good idea.

        Either way, this shouldn't have any effect on RPM packaging, since it uses the SONAME version from upstream and no symbols or any extra files or modifications are requried.

        What are your thoughts on this topic, @pspacek, @vcunat, @dkg, @dsalzman, @mkarpilovskij ?

        [1] - according to debian policy, symbols file is only required for shared libraries https://www.debian.org/doc/debian-policy/#shared-libraries

      • Daniel Kahn Gillmor
        Daniel Kahn Gillmor @dkg ·
        Guest

        I'm the person responsible for putting libkres into a separate library package in debian.

        I did this because (a) it appears to be designed as an independent .so, and (b) i wanted to facilitate experimentation with linking libkres into other applications or language bindings that might want some of this functionality, and (c) i want to make it easier for people to build plugins for kres itself.

        If you think as upstream that this is a terrible idea, then i can rip it out in debian. I think that would be a shame, though.

        as for API stability, as long as nothing is depending on it (which is currently the case), i don't mind if the soname gets bumped regularly -- that's exactly why we document the API, and we can start to see whether it stabilizes or not.

        a changed API causes a slight delay in uploads to debian because of passing through the NEW queue, but that's pretty fast these days, and i don't think it's an actual problem.

        So on balance, i'd prefer to keep it split out as a separate package if y'all are up for it. but i'm also willing to collapse it back again if you have a strong preference.

      • Vladimír Čunát
        Vladimír Čunát @vcunat ·
        Owner

        I haven't heard of any project using libkresd or considering to do so, and we also behave that way. At source-code level it's probably good to split these, but I don't think there's really a benefit from being a so-library. There's probably no reason to remove libkres.so until we show some performance or other benefit of static linking.

      • Tomas Krizek
        Tomas Krizek @tkrizek ·
        Author Owner

        From the perspective of automating builds of development packages, it's quite annoying to have to keep the symbols file updated regularly and it doesn't make much sense for the development versions.

        However, a way around this could be to simply omit the symbols files (!524 (merged)) for development packages. This violates the debian policy, but since we're talking about development version, I don't think it matters.

        Then, we'd only need to update the symbols file when we do an official release. It would allow us to keep libkres as a separate, shared library.

      • Tomas Krizek marked the checklist item @pspacek started a discussion: (+1 comment) as completed

        marked the checklist item @pspacek started a discussion: (+1 comment) as completed

      • Tomas Krizek mentioned in commit e2247757d9d6e432b7270b131087d13dbfc7d80b

        mentioned in commit e2247757d9d6e432b7270b131087d13dbfc7d80b

      • Tomas Krizek mentioned in commit 1d6fef3ffe44354db9294565bf90f800a0438609

        mentioned in commit 1d6fef3ffe44354db9294565bf90f800a0438609

      • Tomas Krizek mentioned in commit dbb403f1f48e0bc7ee72709c2109564b00e7893d

        mentioned in commit dbb403f1f48e0bc7ee72709c2109564b00e7893d

      • Tomas Krizek mentioned in commit 7829467f156bfe723c42b485c9a0ee845032ddf0

        mentioned in commit 7829467f156bfe723c42b485c9a0ee845032ddf0

      • Tomas Krizek mentioned in commit a4124983

        mentioned in commit a4124983

      • Tomas Krizek changed the description

        changed the description

      • Tomas Krizek closed via merge request !540 (merged)

        closed via merge request !540 (merged)

      • Tomas Krizek closed via commit a4124983

        closed via commit a4124983

      • Tomas Krizek mentioned in commit c04ddf16

        mentioned in commit c04ddf16

      • Vladimír Čunát marked the checklist item @pspacek started a discussion: (+1 comment) as completed

        marked the checklist item @pspacek started a discussion: (+1 comment) as completed

      Please register or sign in to reply