On Fri, Apr 07, 2017 at 11:16:05AM -0700, Laura Abbott wrote: > >> > >> It's really not pretty, I spent at least a full day figuring out the > >> regexes because I had no idea how they work. I'm sorely tempted to > >> put some ascii art warning of the horrors within. More macros might help > >> things, I'll see what I can do. What I'd really like is a find-debuginfo.sh > >> flag to add the buildid automatically for the filtering. This might turn > >> into a feature request or a patch if I get around to it. > > > > That was my fear, it was so painful that attempt at future changes, scares > > folks off. :-( > > > > So I just spent some time trying to explore your changes a little bit. I > > thought the VERSION and RELEASE stuff was for the kernel but in fact it > > really is only for the tools (perf and kernel-tools). > > > > Looking at current kernel-tools-debuginfo doesn't show any VERSION and > > RELEASE stuff. Your patch seems to add that. I guess I am curious why? If > > you can only have one version of the tools installed at one time, what does > > VERSION and RELEASE provide us? > > > > My thinking is why don't all the other userspace applications need similar > > naming? > > > > Sorry for being picky, just trying to understand those particular changes. > > > > Switching over to the default find-debuginfo.sh calls adds the unique > build-ids and unique debug names for the kernel. This gets added for > all files, even the userspace components. It seems like this is the > direction find-debuginfo wants to go in so I figured it was worth the > effort to move to it. I went by what needed the ids although maybe I should > take a closer look. Ok. I am still trying to wrap my head around your answer. I think my confusion comes from looking at current debuginfo output and seeing .build-id in there currently. Using kernel version 4.10.8-100.fc24 #rpm -ql kernel-debuginfo |less /usr/lib/debug /usr/lib/debug/.build-id /usr/lib/debug/.build-id/00 /usr/lib/debug/.build-id/00/00cc2f9939c6a8c76892114476ba954c59cc5a /usr/lib/debug/.build-id/00/00cc2f9939c6a8c76892114476ba954c59cc5a.debug /usr/lib/debug/.build-id/00/267f3a96836c45cc8cb8856f7313fc81110528 /usr/lib/debug/.build-id/00/267f3a96836c45cc8cb8856f7313fc81110528.debug <snip> #rpm -ql kernel-tools-debuginfo|less /usr/lib/debug /usr/lib/debug/.build-id /usr/lib/debug/.build-id/0e /usr/lib/debug/.build-id/0e/209e75378bae5b33b3485a5ecc4516e7c765d7 /usr/lib/debug/.build-id/0e/209e75378bae5b33b3485a5ecc4516e7c765d7.debug /usr/lib/debug/.build-id/17 /usr/lib/debug/.build-id/17/36bbf990fedd5bea8a2456c03b03939759ab8b /usr/lib/debug/.build-id/17/36bbf990fedd5bea8a2456c03b03939759ab8b.debug <snip> I see unique .build-id stuff already there. Now comparing your scratch build with say glibc-debuginfo or rpm-debuginfo info, I noticed your scratch build appends a VERSION-RELEASE to every binary name, whereas the other packages do not. On the flip side, the other two packages do add a /usr/src/debug/<pkg>-VERSION-RELEASE/...source files... , which the kernel-tools and perf does not. So I was trying to investigate some of this stuff and noticed that Kyle went down this road a couple of years ago, which Josh reverted the next day in 006e9acec2708eb48b148b3f1ed3cb8e89107447. This looks similar to your work. It seemed to have broken on a 'fedpkg local' for some reason. :-( And then Mark did some magic symlink cleanup in the rpm macros last year, which leads me to wonder, if we can just remove all that ugly '-p' stuff entirely. Of course, I was going to play around with this by short circuiting the kernel build and only build kernel-tools and perf, but my laptop was spitting out kernel config errors with 'make oldconfig' for some reason and bypassing that lead to bizarre EXTRA_CFLAGS macro expansion problems with perf. So I failed there. :-( But my initial thought was to see what happens in the binary images when all that stuff is ripped out and see if /usr/src/debug magically reappears in kernel-tools and perf. At the same time, maybe it makes sense to split this patch in half. Commit the parts we agree on and then continue hacking on this part to include a little later? I could be completely missing something and my thoughts will fail miserably. But at the same time Mark looks willing to help hack find-debuginfo.sh to possible help the kernel? Worth utilizing? :-) Thoughts? Cheers, Don > > Some of this comes back to the problem that the kernel repo doesn't > just have the kernel, it has a bunch of other userspace tools that should > really be a separate repo. As a result we have to keep a bunch of > stuff in the kernel.spec and treat it as a homogeneous project. > Nobody has put in the work to fight for moving stuff out of the kernel > repo so alas we deal with what's there. > > > The rest of the patch looks fine to me. > > > > Thanks, I really appreciate getting a review on this. > > > Cheers, > > Don > > > >> > >> Thanks, > >> Laura > >> _______________________________________________ > >> kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx > >> To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
