dbg packages (was: org.oe.dev wireshark: fix -dbg)

dbg packages (was: org.oe.dev wireshark: fix -dbg)

[Dr. Michael Lauer]

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

Re: dbg packages

[Koen Kooi]

-----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-----

Re: dbg packages

[Rolf Leggewie]

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".

Re: dbg packages

[Dr. Michael Lauer]

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

Re: dbg packages

[Richard Purdie]

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

Re: dbg packages

[Paul Sokolovsky]

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

Re: dbg packages (was: org.oe.dev wireshark: fix -dbg)

[Paul Sokolovsky]

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