Am 06.02.20 um 09:22 schrieb Adam D. Barratt: > On 2020-02-06 08:12, Paul Gevers wrote: >> Hi, >> >> On 06-02-2020 00:07, Adam D. Barratt wrote: >>> On Wed, 2020-02-05 at 22:42 +0000, Sudip Mukherjee wrote: >>>> On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas >>>> <christian@cbarcenas.com> wrote: >>>>> Because this changes the versioning scheme from kernel releases >>>>> (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf >>>>> version numbers (0.0.6-1), the epoch needs to be incremented to 1 I >>>>> believe. >>>> >>>> I had this doubt but 5.4.13-1 is the linux source version, and >>>> libbpf0 has the version of 0.0.5. And since there is no separate >>>> source for libbpf so will this not be considered as a new package >>>> rather than a version change? >>> >>> No. There is currently a libbpf0 binary package. After the source >>> package split, there will still be a libbpf0 binary package. The >>> version of that binary package cannot go backwards. >>> >>> (The source package will indeed be NEW, but that's not the issue under >>> discussion here.) >> >> But, if I am correct, the source could be using a version without epoch >> and only use the epoch in the binary package (which can be dropped if >> libbpf0 is ever replaced by libbpf1). > > Yes. It's a little more work on the packaging side, but entirely > possible to do it that way. There is also libbpf-dev, which could not drop the epoch on a soname bump. Would be kinda odd if going forward libbpfx would not have an epoch and libbpf-dev does. One other alternative could be, to ask your upstream to change the versioning scheme and instead of using 0.0.6, switch to 6.0.0 as first version number (which would be higher then 5.x) Other distros might have similar problems. Michael
Attachment:
signature.asc
Description: OpenPGP digital signature