Package Base Details: bcc

Git Clone URL: (read-only)
Keywords: control eBPF kernel performance tracing
Submitter: troyengel
Maintainer: edh (eklausmeier)
Last Packager: edh
Votes: 28
Popularity: 1.20
First Submitted: 2016-01-01 18:37
Last Updated: 2019-11-07 13:30

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

edh commented on 2017-06-25 19:38

Yes, I would still leave python2-bcc as optional dependency.
All the arguments boil down to an incomplete implementation of the provides field in the AUR and since Arch by default uses python3, I would stick to that version as well. The problem does not exist in the official report and hence there is no official policy.

Either way the most important part is for the package to provide working binaries without additional required optional dependencies.

troyengel commented on 2017-06-21 23:21

*nod* so to be clear, we are then saying by necessity that the python2-bcc bindings will remain optional, correct? The default python for Arch is v3, python2 is not considered the "we expect everyone to have this installed" so if we hard require python2-bcc as well, it would trigger an unwanted python2 on the "standard" Arch where it was not already in place. Or at least I think that's how the maintainers position it (can't seem to find a definitive statement).

As a general user, I have so many things that require py2 that I just want to ensure that we do what's best and not accidentally suck down python2 if it's not considered standard regardless of my personal system. The wiki really doesn't say one way or another, advice welcome.

edh commented on 2017-06-21 15:30

The best solution in the official repos would be to use the provides field just like you proposed. However I guess most AUR helpers will not resolve this correctly. Hence since we are in the AUR and our possibilities are limited, I would settle for specifying python-bcc as hard-dependency.

I agreed that the project handles things pretty unconventional. Considering that the actual executable (python or python3) still resides under /usr/bin, it does not matter that much despite looking odd.
The only thing you can still do is either symlink every tool or add the directory which contains the executables to the PATH.

P.S. Sorry for the late response. To be honst, I simply forgot to sign up for notifications for this package.

troyengel commented on 2017-06-14 23:37

I happen to work with some folks who are paid to be packagers (not for Arch :)) and are Arch users themselves - after some chitchat, we agree that it makes more sense for python-bcc bindings to be a hard dependency.

The issue then to sort - the split package only has one bcc-tools, but you can optionally use py2 or py3 (or both) bindings. The only way I can see this working if we make a requires=python-bcc-bindings (?), then in both split packages add a provides=python-bcc-bindings ? (or maybe a variation of that) We can't just directly require one package or the other... ideas welcome.

@edh - we could add a profile shim, I'm not entirely sure that's right logistically though. What I mean is the /usr/share directory is supposed to be data files, and not a location that would normally be executable in the PATH, it's this project putting the files there as opposed to *bin/ directories (or like /usr/bin/bcc/*) making it a bit weird.. (ref:

Side note, it was pointed out that we can't use makedepends() in the child split package areas (it's just ignored) so those need to get removed next build.

edh commented on 2017-06-08 19:57

Since we are already talking about changing the package :D
Would you mind adding a file which extends the PATH to include /usr/share/bcc/tools.

edh commented on 2017-06-08 19:45

I personally would classify python-bcc as a hard dependency of bcc-tools. Simply because I would expect a *-tools package to provide utility programs not libraries.
However I do not object having an additional lib package which contains merely being a dependency of bcc-tools. Though I would first check whether this new flexibility would be of any use for a current package in the AUR.

troyengel commented on 2017-06-02 16:52

@eklausmeier sorry for the delay, been busy. Mentally I agree, technically it's possible though to use by writing your own python (or whatever). It's one of those areas that I see done differently in Arch than other distros, it's allowable to ship *some* binaries in a package that don't actually work unless you install the optional dependency, as they are not the *core* binary itself. While I think this is a bit odd compared to other methods (apt/dpkg, yum/rpm) it's how Arch works as a design.

All that said, I have no problems myself changing it to required it that's what we think collectively is the right thing to be doing, design patterns or not. Anyone else who happens to see this have thoughts?

eklausmeier commented on 2017-05-29 18:07

I think python-bcc is not an optional but rather a required dependency.

Without python-bcc, for example, execsnoop does not work.

troyengel commented on 2017-03-14 00:20

0.3.0-1 Release Note: 0.3.0 upstream added C++ examples, but their makefiles compile each one with a static copy of libbcc resulting in a huge compile time and space waste (+282megs). I've included a small patch to distribute the raw example *.cc files instead, and submitted an issue upstream:

troyengel commented on 2016-10-18 23:57

I'm about to release a new 0.2.0 package, be aware it does not provide Lua support yet. It appears we need a luajit static library that our luajit package doesn't create, I tagged an upstream issue for help sorting it out: