You are not logged in.
Can anyone help me understand why the linux-headers package now requires the pahole package ?
It used not to.
I am making my custom ZFS package, in fact, I am doing since ZFS 0.8.something and so far so good, and of course, ZFS needs the linux-headers package. Today, I am making updated (ZFS) packages for a system that was not updated in a while and I noticed that linux-headers now wants pahole which itself wants the whole python mountain crap.
PKGBUILD for linux-headers package
I have a python-less system and I will do my best to stay that way.
I was reading (getting a glance-at --should be the term) the pahole man page and it explains:
pahole shows data structure layouts encoded in debugging information formats, DWARF and CTF being supported.
This is useful for, among other things: optimizing important data structures by reducing its size, figuring out what is the field sitting at an offset from the start of a data structure, investigating ABI changes and more generally understanding a new codebase you have to work with.
Does this needs to be mandatory ?
I am not arguing, repeat, not arguing against this situation, I am just trying to understand why it is now necessary and so a required dependency.
Can anyone with far more knowledge explain it to this newbie ?
Offline
Not really now: linux-headers depends on pahole for over a year. The reason.
Staying Pythonless may be hard, since build processes become more and more complex and Python is available everywhere.
Last edited by mpan (2022-04-16 06:04:46)
Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
Thanks for your reply and your link for pahole mpan.
Not really now
Indeed. My use of now was certainly a bit ... lax. I was attempting to update a two-year old offline machine running ZFS 0.8.1 and since my main machine does not have ZFS (and linux-headers) installed I did not notice the pahole requirement.
Staying Pythonless may be hard, since build processes become more and more complex and Python is available everywhere.
Python usage is pervasive --and I think we are not far from the point to start referring to linux as Python-linux instead of GNU-linux ... but that is my personal opinion and nothing else: all those last years with those endless discussions regarding systemd invading everything in linux ... change the word systemd for python and all stands the same.
The machine I was attempting to update it is now fully-reinstalled and up-to-date (sans ZFS of course) (sans GUI --no need for it): 177 packages --no python:
pacstrap /whatever
base sudo pkgconf
linux linux-firmware
apcupsd
texinfo man-pages man-db
gptfdisk e2fsprogs btrfs-progs dosfstools exfat-utils ntfs-3g nfs-utils rsync
lsscsi sdparm sg3_utils smartmontools
minicom openssh sipcalc nmap ntp
less diffutils colordiff vim
make autoconf automake fakeroot gcc dmd
libxml2 libxslt
bind (custom package build without python)
nginx (custom package build without python)
Now, I'll be arguing a bit:
I do not have anything against python per se, but I have everything against python (or any other mega-package by the way) when they start to be required packages by drivers/file-systems or any other thing very close to the core; but ... python being pulled as a dependency for a file-system driver seems totally out-of-place (via pahole via linux-headers).
Can you imagine what would it be like if, for example, e2fsprogs ... required a full-python install ?
Offline
It's not for a filesystem driver. It's for building modules in general. Completely different.
Offline
Not sure whether python is a super-hard dependency of pahole, though.
The only python script in there is "# ostra-cg - generate callgraphs from encoded trace" …
Offline
It's not for a filesystem driver. It's for building modules in general. Completely different.
Sorry Scimmia, you are right, I confused makedepends with depends. Sorry again.
Offline
Not sure whether python is a super-hard dependency of pahole, though.
The only python script in there is "# ostra-cg - generate callgraphs from encoded trace" …
Thanks for your insight about the pahole dependency seth
To give you some context:
I found the zfs/pahole/python dependency issue (to me, that is) just after dealing with other non-related package: mkvtoolnix-cli
mkvtoolnix is a command line tool to manage matroska media containers and was/is a command line tool; that's why it has a cli attached to its name to begin with. There is another related available package for GUI users: mkvtoolnix-gui.
I am using mkvtoolnix since eons ago.
When last upgrading I found pacman wanted a very huge list of packages, almost 700 GB more than usual, and I said ... whaaat ?
I finally pinpointed the issue to mkvtoolnix-cli ,,, it now has a qt5-base dependency wich in turns wants mesa, wayland and whatnot,
For a command-line tool.
So I mailed the maintaners a couple of weeks ago (no answers yet).
Why did I bring this to this topic ?
Because it feels like dependencies are not given much thought these days. It seems (to me) a lot of packages do not need the required dependencies they demand --optional ones could be more than adequate in a lot of cases.
Offline
qt5 also has some library code, it's potentially possible that upstream requires it even for just "cli", have you tried rebuilding it without the dependency to verify whether it really isn't needed? The change was done very deliberately https://github.com/archlinux/svntogit-p … 60f01618bc
FWIW, upstream release notes
## Build system changes
* The Qt library is now required for building all applications, even the
command-line ones, as they use Qt's MIME type detection capabilities. In
turn this means that you cannot disable the Qt usage anymore; either Qt5 or
Qt 6 is required.
https://mkvtoolnix.download/doc/NEWS.md
FWIW if you personally want to avoid these GUI deps for your own server system, consider using e.g.: https://aur.archlinux.org/packages/qt5-base-headless
But that's somewhat off topic, for getting the pahole dependency demoted to optional, you could try to drop it/rebuild locally without the python dependency and check whether you can still build the kernel modules you need the headers for.
Last edited by V1del (2022-04-17 19:26:48)
Offline
qt5 also has some library code, it's potentially possible that upstream requires it even for just "cli", have you tried rebuilding it without the dependency to verify whether it really isn't needed? The change was done very deliberately https://github.com/archlinux/svntogit-p … 60f01618bc
FWIW, upstream release notes
mkvtoolnix release notes wrote:## Build system changes
* The Qt library is now required for building all applications, even the
command-line ones, as they use Qt's MIME type detection capabilities. In
turn this means that you cannot disable the Qt usage anymore; either Qt5 or
Qt 6 is required.
Huh ... bad news. Although I try to avoid building custom packages to a bare minimum after this issue I did make a note to consider adding mkvtoolnix to my list, but since I didn't do my research on it yet I didn't expect to be an upstream requirement. Anyway, even after mkvtoolnix requiring some MIME code from qt I suspect the qt5base package is overkill even for building it -if you need to retrieve mesa, wayland, and whatnot just to use some MIME code ... hmmmm.
FWIW if you personally want to avoid these GUI deps for your own server system, consider using e.g.: https://aur.archlinux.org/packages/qt5-base-headless
I didn't know this package ever existed --thanks for the tip V1del.
I'ĺl try to build it with this one and see how far can I go, I'll keep you posted.
Thanks for your reply !
Offline