From: Paul Sokolovsky <pmiscml@gmail.com>
To: Richard Purdie <rpurdie@rpsys.net>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: dbg packages
Date: Tue, 10 Jul 2007 15:54:38 +0300 [thread overview]
Message-ID: <602819948.20070710155438@gmail.com> (raw)
In-Reply-To: <1184064667.6435.45.camel@localhost.localdomain>
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
next prev parent reply other threads:[~2007-07-10 13:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
2007-07-09 22:52 ` dbg packages (was: org.oe.dev wireshark: fix -dbg) Paul Sokolovsky
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=602819948.20070710155438@gmail.com \
--to=pmiscml@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
--cc=rpurdie@rpsys.net \
/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 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.