On Thu, Feb 6, 2020 at 11:07 AM Sudip Mukherjee <sudipm.mukher...@gmail.com> wrote: > > On Thu, Feb 6, 2020 at 8:39 AM Michael Biebl <bi...@debian.org> wrote: > > > > 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 > > >>>> <christ...@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? > > >>> > <snip> > > > > 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. > > I think other distros already had the package split and are now using > the source from github. Atleast Fedora and Gentoo have done already. > Looks like Fedora solved the problem using epoch as can be seen in the > comment at > https://src.fedoraproject.org/rpms/libbpf/blob/f30/f/libbpf.spec#_15
And, I have confirmed from Jiri who is the Fedora maintainer for libbpf that they have used epoch to solve the version problem. So, do we also use epoch or shall I try the way which Paul suggested to add epoch only to the binary package? -- Regards Sudip