Github messages for voidlinux
 help / color / mirror / Atom feed
From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: shlibs checking fail on neovim update
Date: Sat, 28 Dec 2019 15:04:29 +0100	[thread overview]
Message-ID: <20191228140429.GZHS3I1eGqfFhBlUufdEW3EILh8cOVdGPx5RsjhNLQc@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-14856@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/14856#issuecomment-569419722

Comment:
This is a more general issue, adding new symbols doesn't break the ABI so they don't really have to bump the version.
The same happens with glibc and libressl, where we just bump the the minimum version in `common/shlibs` so packages build against a new `glibc` or `libressl` version that might use a new or in glibcs case a new versioned symbol will not break and depend on the new version.

Not sure what we can do about it, we could just depend on `>=` of the exact package version we linked against instead of `common/shlibs` but then selective/partial updates and installs become a lot less doable.

Edit:
The best solution would be a way to not just record SONAMEs but also record earch symbol and then check the compiled binaries needed symbols against the record and then take the highest version of the required symbols as minimum version instead of `common/shlibs` version.

  parent reply	other threads:[~2019-12-28 14:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30 17:40 [ISSUE] " voidlinux-github
2019-12-27 22:20 ` voidlinux-github
2019-12-28 12:09 ` voidlinux-github
2019-12-28 14:00 ` voidlinux-github
2019-12-28 14:04 ` voidlinux-github [this message]
2019-12-30 13:59 ` voidlinux-github
2019-12-30 14:00 ` voidlinux-github
2019-12-30 14:15 ` voidlinux-github
2019-12-30 14:17 ` voidlinux-github
2019-12-30 14:18 ` voidlinux-github
2019-12-30 15:38 ` voidlinux-github
2019-12-30 15:38 ` voidlinux-github
2019-12-30 15:39 ` voidlinux-github
2019-12-30 15:41 ` voidlinux-github
2019-12-30 15:41 ` voidlinux-github
2019-12-30 15:42 ` voidlinux-github
2019-12-30 15:42 ` voidlinux-github
2019-12-30 15:43 ` voidlinux-github
2019-12-30 17:28 ` voidlinux-github
2019-12-30 17:29 ` voidlinux-github
2019-12-30 17:48 ` voidlinux-github
2021-02-05  3:25 ` ericonr
2022-04-15  2:12 ` github-actions
2022-07-19  2:13 ` github-actions
2022-08-02  2:13 ` [ISSUE] [CLOSED] " github-actions

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191228140429.GZHS3I1eGqfFhBlUufdEW3EILh8cOVdGPx5RsjhNLQc@z \
    --to=voidlinux-github@inbox.vuxu.org \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).