On Tue, 7 Aug 2007 15:44:27 +0200 Loïc Minier <lool@dooz.org> wrote: > On Tue, Aug 07, 2007, Neil Williams wrote: > > i.e. the reverse sense - the dbg name should be forced to use the lib > > prefix where the only packages built from that source already use the > > lib prefix. > > > > This is (IMHO) implicit in "library source package". > > I think the package name should not be specified by policy; it would > simply be natural to use such a name. The requirement could simply be: > source packages shipping at least one (public) shared library must > ship detached debug symbols for this library in a debug package OK. With some explanation of how easy this usually is to achieve in the Developers Reference, I'd be happy with that. IIRC, Manoj preferred to make this a recommend before migrating to a must to limit the number of packages that are immediately made RC buggy. Hopefully, there is time to get to 'must' before Lenny. > > I wondered about that. Take gpe-expenses - if a new application > > (gpe-cash) depends on libqofexpensesobjects0 (and provides another > > shared library too) then I don't see why someone debugging gpe-cash > > should be obliged to install the debug symbols for gpe-expenses as > > well as libqofexpensesobjects. > > Would it matter? Do we really want to foresee in policy whether the > debug symbols of package x are too large to be along package y's debug > symbols? I think we should simply require debugging symbols and > recommend a single package where it makes sense. It's never too late > to notice that a -dbg is huge and could be usefully split. That's fair. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp9E6NFQA0By.pgp
Description: PGP signature