netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Julia Kartseva <hex@fb.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	"labbott@redhat.com" <labbott@redhat.com>,
	"acme@kernel.org" <acme@kernel.org>,
	"debian-kernel@lists.debian.org" <debian-kernel@lists.debian.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Andrii Nakryiko <andriin@fb.com>, Andrey Ignatov <rdna@fb.com>,
	Alexei Starovoitov <ast@fb.com>, Yonghong Song <yhs@fb.com>,
	"jolsa@kernel.org" <jolsa@kernel.org>
Subject: Re: libbpf distro packaging
Date: Wed, 21 Aug 2019 23:09:06 +0200	[thread overview]
Message-ID: <20190821210906.GA31031@krava> (raw)
In-Reply-To: <A770810D-591E-4292-AEFA-563724B6D6CB@fb.com>

On Tue, Aug 20, 2019 at 10:27:23PM +0000, Julia Kartseva wrote:
> 
> 
> On 8/19/19, 11:08 AM, "Julia Kartseva" <hex@fb.com> wrote:
> 
>     On 8/13/19, 11:24 AM, "Andrii Nakryiko" <andrii.nakryiko@gmail.com> wrote:
>     
>         On Tue, Aug 13, 2019 at 5:26 AM Jiri Olsa <jolsa@redhat.com> wrote:
>         >
>         > On Mon, Aug 12, 2019 at 07:04:12PM +0000, Julia Kartseva wrote:
>         > > I would like to bring up libbpf publishing discussion started at [1].
>         > > The present state of things is that libbpf is built from kernel tree, e.g. [2]
>         > > For Debian and [3] for Fedora whereas the better way would be having a
>         > > package built from github mirror. The advantages of the latter:
>         > > - Consistent, ABI matching versioning across distros
>         > > - The mirror has integration tests
>         > > - No need in kernel tree to build a package
>         > > - Changes can be merged directly to github w/o waiting them to be merged
>         > > through bpf-next -> net-next -> main
>         > > There is a PR introducing a libbpf.spec which can be used as a starting point: [4]
>         > > Any comments regarding the spec itself can be posted there.
>         > > In the future it may be used as a source of truth.
>         > > Please consider switching libbpf packaging to the github mirror instead
>         > > of the kernel tree.
>         > > Thanks
>         > >
>         > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.iovisor.org_g_iovisor-2Ddev_message_1521&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=zUrDY_Sp_5PqcGtRQPNeDA&m=prYVDiu3-aH1o2PWH4ZcP7lEQRCQAcTwcWPrJrtaroQ&s=dYAc2jLhFg0wtCZ_ms2HF5bWANoHzA3UMug5TNCeBtE&e= 
>         > > [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__packages.debian.org_sid_libbpf4.19&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=zUrDY_Sp_5PqcGtRQPNeDA&m=prYVDiu3-aH1o2PWH4ZcP7lEQRCQAcTwcWPrJrtaroQ&s=lq1MpF-bt6y6ZEtFc57eT-BO_wMBx8uUBACJooWbUYk&e= 
>         > > [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__rpmfind.net_linux_RPM_fedora_devel_rawhide_x86-5F64_l_libbpf-2D5.3.0-2D0.rc2.git0.1.fc31.x86-5F64.html&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=zUrDY_Sp_5PqcGtRQPNeDA&m=prYVDiu3-aH1o2PWH4ZcP7lEQRCQAcTwcWPrJrtaroQ&s=NoolYHL57G2KhzE768iWdy6v5LD2GfJQyqPmtjy196E&e= 
>         > > [4] https://github.com/libbpf/libbpf/pull/64
>         >
>         > hi,
>         > Fedora has libbpf as kernel-tools subpackage, so I think
>         > we'd need to create new package and deprecate the current
>         >
>         > but I like the ABI stability by using github .. how's actually
>         > the sync (in both directions) with kernel sources going on?
>         
>         Sync is always in one direction, from kernel sources into Github repo.
>         Right now it's triggered by a human (usually me), but we are using a
>         script that automates entire process (see
>         https://github.com/libbpf/libbpf/blob/master/scripts/sync-kernel.sh).
>         It cherry-pick relevant commits from kernel, transforms them to match
>         Github's file layout and re-applies those changes to Github repo.
>         
>         There is never a sync from Github back to kernel, but Github repo
>         contains some extra stuff that's not in kernel. E.g., the script I
>         mentioned, plus Github's Makefile is different, because it can't rely
>         on kernel's kbuild setup.
> 
> Hi Jiri,
> I'm curious if you have any comments regarding sync procedure described
> By Andrii. Or if there is anything else you'd like us to address so Fedora
> can be switched to libbpf built from the github mirror?

hi,
yea, I think it's ok.. just need to check the implications
for rhel packaging and I'll let you know

jirka

  reply	other threads:[~2019-08-21 21:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-12 19:04 libbpf distro packaging Julia Kartseva
2019-08-13 12:24 ` Jiri Olsa
2019-08-13 14:11   ` Daniel Borkmann
2019-08-13 18:26     ` Andrii Nakryiko
2019-08-13 18:23   ` Andrii Nakryiko
     [not found]     ` <FA139BA4-59E5-43C7-8E72-C7B2FC1C449E@fb.com>
2019-08-20 22:27       ` Julia Kartseva
2019-08-21 21:09         ` Jiri Olsa [this message]
2019-08-23  9:22           ` Jiri Olsa
2019-08-23 16:00             ` Alexei Starovoitov
2019-08-26  6:42               ` Jiri Olsa
2019-08-27 22:30                 ` Julia Kartseva
2019-08-28  7:12                   ` Jiri Olsa
2019-09-30 11:13                     ` Jiri Olsa
2019-09-30 18:18                       ` Julia Kartseva
2019-10-03  0:50                         ` Julia Kartseva
2019-10-03 11:10                           ` Jiri Olsa
2019-10-03 16:24                             ` Andrii Nakryiko
2019-10-03 17:29                               ` Jiri Olsa
2019-10-07  0:25                       ` Julia Kartseva
2019-10-08  7:39                         ` Jiri Olsa
2019-10-11 21:14                           ` Julia Kartseva
2019-10-16 10:01                             ` Jiri Olsa
2019-12-19 21:37                               ` Julia Kartseva
2019-12-20 13:58                                 ` Jiri Olsa
2020-03-05  0:22                                   ` Julia Kartseva
2020-03-05 14:18                                     ` Jiri Olsa
2020-03-10 14:57                                       ` Jiri Olsa
2020-03-10 17:18                                         ` Julia Kartseva
2020-03-10 17:49                                           ` Jiri Olsa

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=20190821210906.GA31031@krava \
    --to=jolsa@redhat.com \
    --cc=acme@kernel.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=debian-kernel@lists.debian.org \
    --cc=hex@fb.com \
    --cc=jolsa@kernel.org \
    --cc=labbott@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rdna@fb.com \
    --cc=yhs@fb.com \
    /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).