On Tue, 7 Aug 2007 14:08:35 +0200 Loïc Minier <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 07, 2007, Neil Williams wrote:
> > The principle here is to make upstream development on Debian easier
>
> To be clear, the only part I'm not confortable about is forcing the dbg
> name to start with the name of the shared library package as it might
> not make sense in the nautilus case or when a source builds multiple
> shared library packages (having two -dbg for two indepent libraries
> built from the same source would bloat the archive needlessly).
OK - a source that builds only a shared library and attendant packages
(-dev, -doc etc.) must use the lib prefix for the -dbg, just as with
the shared library itself. e.g. qof must provide libqof(.*)-dbg and not
qof-dbg.
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 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.
Emdebian now uses .deb and all the normal Debian package tools (like
dpkg-foo, dh_foo, reprepro, dput, debc etc.) work fine. If this works
for Emdebian (where dependencies are routinely rearranged and all
packages are cross-built with multiple changes from the Debian version)
I don't see why it would be a problem for -dbg. .ddeb is not necessary
merely to segregate -dbg packages within repositories.
IMHO putting all -dbg packages into Priority: extra is sufficient.
> > Source packages that provide an application and a *shared* library (i.e.
> > one with a -dev package) can provide a -dbg to complement the -dev but
> > that isn't expressly part of this proposal.
>
> I do think one source package should aim at providing only one -dbg
> package when possible.
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.
It's different when developing, say, nautilus-extensions where the new
code itself is likely to be used within nautilus but when the
application linked against the shared library is not loaded by or
within the other application, why should all the symbols be installed?
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.
> > > We don't really need to keep -dbg for the transitional period where two
> > > SONAMEs of the same lib from the same source are on user systems and we
> > > can have very lax dependencies in the -dbg packages and on the -dbg
> > > packages.
> > ? To debug libfoo1 you must have libfoo1-dbg, libfoo0-dbg won't work.
> > The dependency needs to be fixed as:
> > Depends: ${binary:Version}
> > i.e. libfoo1-dbg 1.2.3-4 depends on libfoo1 1.2.3-4
>
> But if libfoo1 is around, then libfoo0 is already in the process of
> going away (if you mean a SONAME change in a source); if you build two
> SONAME from two sources, or two SONAME from the same source, you can
> still ship the -dbg of each build in one -dbg per source, there's no
> technical issue. On the other hand, renaming the -dbg to carry the
> SONAME is gratuitous and doesn't have any additional value.
So as long as "Depends: ${binary:Version}" remains, there is no need
for the SONAME in the -dbg package name? That seems OK to me.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpl4DFT4xj4H.pgp
Description: PGP signature
