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
> > I join Mike's feeling that we would be best served by a ddeb
> > infrastructure.
>
> Having looked into a .emdeb for Emdebian in quite a lot of depth and
> discarded the idea as simply FAR too much work fixing all the package
> tools, I have to wonder if this is remotely sensible.
We have two real life implementations:
- D-I uses udebs
- Ubuntu uses ddebs
> 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.
> e.g. Imagine if gnumeric or gnucash provided a shared library that was
> used by gnotime or some other gnome app. It would not make sense to
> require the gnucash debug symbols to be installed as well. All that is
> needed is the library debug symbols as gnucash isn't loading the test
> application, the test application is merely linked against some code
> that is also linked against gnucash. The gnucash symbols are only
> needed when debugging gnucash, not the library.
I don't want policy to require or encourage splitting in too many
binary packages: by this logic, we could require development packages
to systematically split headers, API documentation, and development
utilities because one might need one functionality and not the others,
or we could aim at having one binary package per utility because one
doesn't need "nautilus-connect-server" or
"nautilus-file-management-properties".
--
Loïc Minier
