On 4/26/13 9:50 AM, Otavio Salvador wrote:
On Fri, Apr 26, 2013 at 11:41 AM, Phil Blundell <[email protected]> wrote:
On Fri, 2013-04-26 at 09:39 -0500, Mark Hatle wrote:
On 4/26/13 9:27 AM, Phil Blundell wrote:
On Fri, 2013-04-26 at 09:16 -0500, Mark Hatle wrote:
The alternative of course is to crease special -dbg packages for the two
conflicting items.  I.e. foo-dbg, foo-sulogin-dbg, bar-dbg and 
bar-sulogin-dbg...

Yeah, indeed, that's what I suggested in my original email.  At the time
I thought that would be hard to arrange (in the general case), but
having given it some further consideration perhaps it isn't all that bad
after all.

I certainly wouldn't be against an enhancement that tries to match up the
binaries to their debug and create suitably named -dbg packages.  The only
tricky part is what to do with the associated sources?  Since those are not
arranged according to binaries, but generally for the whole recipe.

The sources can stay where they are, in ${PN}-dbg.  There won't be any
conflict there because the installed files are already namespaced by
recipe.

Maybe add a ${PN}-source with it? So any -dbg could rdepends on it?

-dbg-source would be better.. but I don't mind that. I know there have been complaints where people want the debug symbols on the target, but don't want the debug sources. This could address that as well.

I'd suggest someone (Phil ?) collect these and add a open an enhancement bug in the YP bugzilla. That way progress on implementation can be tracked. (Unless of course someone just implements it.. but I'm guessing it won't be quite that straightforward.)

--Mark

--
Otavio Salvador                             O.S. Systems
E-mail: [email protected]  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br



_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to