* dbg packages (was: org.oe.dev wireshark: fix -dbg) [not found] <E1I7yE2-0000V0-1x@linuxtogo.org> @ 2007-07-09 19:57 ` Dr. Michael Lauer 2007-07-09 20:11 ` dbg packages Koen Kooi 2007-07-09 22:52 ` dbg packages (was: org.oe.dev wireshark: fix -dbg) Paul Sokolovsky 0 siblings, 2 replies; 7+ messages in thread From: Dr. Michael Lauer @ 2007-07-09 19:57 UTC (permalink / raw) To: openembedded-devel koen commit wrote: > wireshark: fix -dbg [...] > + > +FILES_${PN}-dbg += "${libdir}/wireshark/plugins/${PV}/.debug" > + > + We keep adding this stuff more and more -- since more and more packages go from a monolithic state to an extensible -- and I don't like having to specify this all over. Can't we get the dbg package to pick up all .debug directories automatically? Regards, :M: -- Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dbg packages 2007-07-09 19:57 ` dbg packages (was: org.oe.dev wireshark: fix -dbg) Dr. Michael Lauer @ 2007-07-09 20:11 ` Koen Kooi 2007-07-09 22:05 ` Rolf Leggewie 2007-07-09 22:52 ` dbg packages (was: org.oe.dev wireshark: fix -dbg) Paul Sokolovsky 1 sibling, 1 reply; 7+ messages in thread From: Koen Kooi @ 2007-07-09 20:11 UTC (permalink / raw) To: openembedded-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dr. Michael Lauer schreef: > koen commit wrote: >> wireshark: fix -dbg > [...] >> + >> +FILES_${PN}-dbg += "${libdir}/wireshark/plugins/${PV}/.debug" >> + >> + > > We keep adding this stuff more and more -- since more and more > packages go from a monolithic state to an extensible -- and > I don't like having to specify this all over. Can't we get the dbg > package to pick up all .debug directories automatically? In this case I'd say "make wireshark even more granular by subpackaging its 2 shlibs and plugins", which would not want every .debug directory in ${PN}-dbg. In the general case I'm not sure if we want something automagically added to ${PN}-dbg or not, since it is likely to be wrong in a lot of cases. So I'm not sure if something automagically would cause more or less work for packages I want to add/maintain/fix. What I would like to see implemented is some heuristic that puts .debug/<foo> in the -dbg (sub)package that is named after the (sub)package that has <foo> (e.g. create wireshark-plugin-<foo>-dbg automagically after finding <foo> in wireshark-plugin-<foo>). Same goes for lib<foo>-dev automagically getting lib<foo>.{so,a,la,pc}, headers will have to get sorted by hand. Packaging is tedious, but let's not automate doing the wrong thing ;) regards, Koen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGkpZzMkyGM64RGpERAnhTAJsGakQCTjzec/sLVBoA9Zb/S6D7VwCdE8Qz pnvest3WtETPsF4K93kWHWI= =FrV+ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dbg packages 2007-07-09 20:11 ` dbg packages Koen Kooi @ 2007-07-09 22:05 ` Rolf Leggewie 2007-07-10 9:21 ` Dr. Michael Lauer 0 siblings, 1 reply; 7+ messages in thread From: Rolf Leggewie @ 2007-07-09 22:05 UTC (permalink / raw) To: openembedded-devel Koen Kooi wrote: > Packaging is tedious, but let's not automate doing the wrong thing ;) I certainly agree with the general statement. But I wonder if in this case it would not be OK to have just one big -dbg package per bb file even if there are more subpackages. Going granular is certainly nice but I wonder if just having a dbg package suffices even if contains more than necessary. I guess the -dbg packages should not be necessary most of the time. My vote would go for "bigger size" if it means "easier packaging right now instead of later" unless that entails "something breaks". ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dbg packages 2007-07-09 22:05 ` Rolf Leggewie @ 2007-07-10 9:21 ` Dr. Michael Lauer 2007-07-10 10:51 ` Richard Purdie 0 siblings, 1 reply; 7+ messages in thread From: Dr. Michael Lauer @ 2007-07-10 9:21 UTC (permalink / raw) To: Rolf Leggewie; +Cc: openembedded-devel Rolf Leggewie wrote: > Koen Kooi wrote: >> Packaging is tedious, but let's not automate doing the wrong thing > I certainly agree with the general statement. But I wonder if in this > case it would not be OK to have just one big -dbg package per bb file > even if there are more subpackages. Going granular is certainly nice > but I wonder if just having a dbg package suffices even if contains more > than necessary. I guess the -dbg packages should not be necessary most > of the time. > My vote would go for "bigger size" if it means "easier packaging right > now instead of later" unless that entails "something breaks". I totally agree. If I have to decide between slightly less granular packaging of debug packages vs. tedious error-prone repetetive stating of packaging for debug packages I gladly chose the first one. For debugging, one or very few packages per recipe makes perfect sense to me. Regards, :M: -- Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dbg packages 2007-07-10 9:21 ` Dr. Michael Lauer @ 2007-07-10 10:51 ` Richard Purdie 2007-07-10 12:54 ` Paul Sokolovsky 0 siblings, 1 reply; 7+ messages in thread From: Richard Purdie @ 2007-07-10 10:51 UTC (permalink / raw) To: openembedded-devel; +Cc: Rolf Leggewie On Tue, 2007-07-10 at 11:21 +0200, Dr. Michael Lauer wrote: > Rolf Leggewie wrote: > > Koen Kooi wrote: > >> Packaging is tedious, but let's not automate doing the wrong thing > > > I certainly agree with the general statement. But I wonder if in this > > case it would not be OK to have just one big -dbg package per bb file > > even if there are more subpackages. Going granular is certainly nice > > but I wonder if just having a dbg package suffices even if contains more > > than necessary. I guess the -dbg packages should not be necessary most > > of the time. > > > My vote would go for "bigger size" if it means "easier packaging right > > now instead of later" unless that entails "something breaks". > > I totally agree. If I have to decide between slightly less granular > packaging of debug packages vs. tedious error-prone repetetive stating > of packaging for debug packages I gladly chose the first one. > > For debugging, one or very few packages per recipe makes perfect sense to me. I also agree for what its worth, having one -dbg package per recipe isn't really a hardship since when you're debugging you usually have enough space not to worry about the slight extra space usage. In the past I've gone for the one -dbg package approach when packaging apps. Automating the debug package generation would be good. The best way to do it would probably be to allow full regexps in FILES rather than the existing rather limited python globs. Can we convert and maintain backwards compatibility? Cheers, Richard ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dbg packages 2007-07-10 10:51 ` Richard Purdie @ 2007-07-10 12:54 ` Paul Sokolovsky 0 siblings, 0 replies; 7+ messages in thread From: Paul Sokolovsky @ 2007-07-10 12:54 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-devel Hello Richard, Tuesday, July 10, 2007, 1:51:07 PM, you wrote: > On Tue, 2007-07-10 at 11:21 +0200, Dr. Michael Lauer wrote: >> Rolf Leggewie wrote: >> > Koen Kooi wrote: >> >> Packaging is tedious, but let's not automate doing the wrong thing >> >> > I certainly agree with the general statement. But I wonder if in this >> > case it would not be OK to have just one big -dbg package per bb file >> > even if there are more subpackages. Going granular is certainly nice >> > but I wonder if just having a dbg package suffices even if contains more >> > than necessary. I guess the -dbg packages should not be necessary most >> > of the time. >> >> > My vote would go for "bigger size" if it means "easier packaging right >> > now instead of later" unless that entails "something breaks". >> >> I totally agree. If I have to decide between slightly less granular >> packaging of debug packages vs. tedious error-prone repetetive stating >> of packaging for debug packages I gladly chose the first one. >> >> For debugging, one or very few packages per recipe makes perfect sense to me. > I also agree for what its worth, having one -dbg package per recipe > isn't really a hardship since when you're debugging you usually have > enough space not to worry about the slight extra space usage. In the > past I've gone for the one -dbg package approach when packaging apps. > Automating the debug package generation would be good. The best way to > do it would probably be to allow full regexps in FILES rather than the > existing rather limited python globs. Can we convert and maintain > backwards compatibility? Let's add REFILES then? But mind empty dirs issue. Maybe for -dbg it's worth to just add a specialized task? (REFILES are useful on their own of course). > Cheers, > Richard -- Best regards, Paul mailto:pmiscml@gmail.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dbg packages (was: org.oe.dev wireshark: fix -dbg) 2007-07-09 19:57 ` dbg packages (was: org.oe.dev wireshark: fix -dbg) Dr. Michael Lauer 2007-07-09 20:11 ` dbg packages Koen Kooi @ 2007-07-09 22:52 ` Paul Sokolovsky 1 sibling, 0 replies; 7+ messages in thread From: Paul Sokolovsky @ 2007-07-09 22:52 UTC (permalink / raw) To: Dr. Michael Lauer; +Cc: openembedded-devel Hello Dr., Monday, July 9, 2007, 10:57:55 PM, you wrote: > koen commit wrote: >> wireshark: fix -dbg > [...] >> + >> +FILES_${PN}-dbg += "${libdir}/wireshark/plugins/${PV}/.debug" >> + >> + > We keep adding this stuff more and more -- since more and more > packages go from a monolithic state to an extensible -- and > I don't like having to specify this all over. Can't we get the dbg > package to pick up all .debug directories automatically? That's what I was thinking for some time now too. It's good that bitbake is expressive enought that we *can* so that with its generic means like FILES, but doing that again and again instead once and for all is really boring. And there's another issue here - empty .debug directories throught the rootfs. This one is actually more complex, as empty directories are there because of package-write task's workings, and sometimes we want them, sometimes not, so it's unclear how to handle that issue. At least we for sure don't want empty .debug/'s. > Regards, > :M: -- Best regards, Paul mailto:pmiscml@gmail.com ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2007-07-10 13:00 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1I7yE2-0000V0-1x@linuxtogo.org>
2007-07-09 19:57 ` dbg packages (was: org.oe.dev wireshark: fix -dbg) Dr. Michael Lauer
2007-07-09 20:11 ` dbg packages Koen Kooi
2007-07-09 22:05 ` Rolf Leggewie
2007-07-10 9:21 ` Dr. Michael Lauer
2007-07-10 10:51 ` Richard Purdie
2007-07-10 12:54 ` Paul Sokolovsky
2007-07-09 22:52 ` dbg packages (was: org.oe.dev wireshark: fix -dbg) Paul Sokolovsky
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.