Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Fri, Feb 7, 2020 at 7:58 PM Sudip Mukherjee wrote: > > On Fri, Feb 7, 2020 at 10:17 AM Sudip Mukherjee > wrote: > > > > On Thu, Feb 6, 2020 at 10:53 PM Christian Barcenas > > wrote: > > > > > > I just noticed that your packaging repo is currently empty. > > > Would you be able to push your current progress to Github > > > so that it's easier to review the source package? > > > > Pushed now. Its without any epoch in the version. I will add the epoch > > and push again tonight after back from $dayjob. > > Also pushed in wip/epoch branch with the epoch in only binary packages > for your review. I have not yet uploaded to mentors. And I have now pushed to mentors the package with epoch only in the binary packages and I hope that is the consensus here. -- Regards Sudip
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Fri, Feb 7, 2020 at 10:17 AM Sudip Mukherjee wrote: > > On Thu, Feb 6, 2020 at 10:53 PM Christian Barcenas > wrote: > > > > I just noticed that your packaging repo is currently empty. > > Would you be able to push your current progress to Github > > so that it's easier to review the source package? > > Pushed now. Its without any epoch in the version. I will add the epoch > and push again tonight after back from $dayjob. Also pushed in wip/epoch branch with the epoch in only binary packages for your review. I have not yet uploaded to mentors. -- Regards Sudip
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Thu, 2020-02-06 at 09:39:29 +0100, Michael Biebl wrote: > Am 06.02.20 um 09:22 schrieb Adam D. Barratt: > > On 2020-02-06 08:12, Paul Gevers wrote: > > > 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. While this case is precisely what epochs were designed for, I'd still try to minimize its usage here as much as possible. And go for no epoch on the source packages, and prefixing the epoch in the binary packages, because the one in libbpf1 could then be dropped. > 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. We already have similar cases in the archive. And the nice thing of not going with a full epoch bump is that it can always be bumped for the source later on, while the reverse is not possible. :) > 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. That might be even better, yes. :) Thanks, Guillem
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Thu, Feb 6, 2020 at 10:53 PM Christian Barcenas wrote: > > I just noticed that your packaging repo is currently empty. > Would you be able to push your current progress to Github > so that it's easier to review the source package? Pushed now. Its without any epoch in the version. I will add the epoch and push again tonight after back from $dayjob. -- Regards Sudip
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
I just noticed that your packaging repo is currently empty. Would you be able to push your current progress to Github so that it's easier to review the source package? On Thu, Feb 6, 2020 at 2:34 PM Sudip Mukherjee wrote: > So, do we also use epoch or shall I try the way which Paul suggested > to add epoch only to the binary package? My vote is to use libbpf's new versioning scheme and epoch 1 for both source and binary packages. The primary benefit is simplicity: IMO it's easier to reason about things that way. It looks like upstream is trying to separate their own release schedule from the kernel's. There is now a possibility that some future libbpf release may contain changes not present in the upstream kernel tree at all. In this scenario, it would *only* make sense to use libbpf versioning for the source package, so we might as well get both epoch adjustments out of the way right now instead of raising this question again in the future. Christian
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Thu, Feb 6, 2020 at 11:07 AM Sudip Mukherjee wrote: > > On Thu, Feb 6, 2020 at 8:39 AM Michael Biebl 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 +, Sudip Mukherjee wrote: > > On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas > > 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? > > >>> > > > > > 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
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Thu, Feb 6, 2020 at 8:39 AM Michael Biebl 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 +, Sudip Mukherjee wrote: > On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas > 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? > >>> > > 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 -- Regards Sudip
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
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 +, Sudip Mukherjee wrote: On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas 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 signature.asc Description: OpenPGP digital signature
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
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 +, Sudip Mukherjee wrote: On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas 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. Regards, Adam
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
Hi, On 06-02-2020 00:07, Adam D. Barratt wrote: > On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote: >> On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas >> 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). Paul
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote: > On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas > 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.) Regards, Adam
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas 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? -- Regards Sudip
Re: Bug#950760: RFS: libbpf/0.0.6-1 -- eBPF helper library (development files)
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. CC'ing debian-devel for discussion/consensus, per Debian Policy Manual 5.6.12. Christian On Wed, Feb 5, 2020 at 12:57 PM Sudip Mukherjee wrote: > > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "libbpf" > > * Package name: libbpf >Version : 0.0.6-1 >Upstream Author : NA > * URL : https://github.com/libbpf/libbpf > * License : LGPL-2.1 > * Vcs : https://github.com/sudipm-mukherjee/libbpf >Section : libs > > It builds those binary packages: > > libbpf-dev - eBPF helper library (development files) > libbpf0 - eBPF helper library (shared library) > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/libbpf > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/libb/libbpf/libbpf_0.0.6-1.dsc > > Changes since the last upload: > >* Package from github. (Closes: #948041) > > Note: > I think this should be done after > https://salsa.debian.org/kernel-team/linux/merge_requests/207 > has been merged. > > > -- > Regards > Sudip >
