"A" build-depends on "B"'s source: what to do
I'm asking this question as package "B"'s maintainer. I'll describe
the problem and my proposed solution to it. I'll be eager to hear
anyone's comments.
Executive summary: Package "B" requires a configured copy of package
"A"'s source tree in order to build itself. I'm proposing to split
package "A"'s -dev package into -dev, -source, and -config packages.
The -dev package contains what a normal application that builds
against package "A" would need while the architecture-independent
-source package and the architecture-depend -config package contain
the extracted source tree and the files created by ./configure
respectively. The -source and -config packages would install into
/usr/src. My main questions are whether this approach seems sound (I
think it does), whether there are other packages that do this and what
they do, and whether the names and the installation locations for the
-source and -config packages seem right.
---
Now for the specifics.
The "pathan" package (http://software.decisionsoft.com), which is not
currently packaged for Debian, requires a configured copy of the
xerces-c source tree to be present while it is being built because it
uses private files from the source package that are not installed,
even in the -dev package. Although this could be considered to be the
result of a deficiency in the way the xerces packages are handled
upstream, it is still a fact of life that it is this way. This
doesn't have anything to do with Debian or the Debian packages.
A user who was trying to build pathan posted a bug against the
libxerces23-dev package (bug 215079) asking that libxerces23-dev
supply some private header files so that pathan could be built. I
feel that this is an incorrect solution -- in general, we should
respect what upstream maintainers decide should and shouldn't be
installed. Creating a situation where a user could *accidentally*
depend upon a private xerces file would be a disservice to the
developer community as it create a situation where people could
accidentally create packages that would work on Debian but not work on
other platforms.
Still, it would be good to be able to accommodate the user in some
other way. In the case of building pathan, a configured extracted
source tree is required. In the case of building libxml-xerces-perl,
the config.status file is required but nothing else from the source
tree is. By the nature of the xerces packages, I suspect that this
may be an unfortunately common situation for xerces and things that
depend upon it. It is definitely the case that external packages that
depend upon xerces tend to depend upon specific versions of xerces and
that new upstream versions of xerces often require modifications to
software that builds against it.
I have a proposed solution to this problem, but I want to run it by
the list first in case there is precedent or someone has a better
idea.
I'll talk about only xerces25 for clarity, but everything I say
applies equally to xerces23 and xerces24. Right now, the xerces25
source package generates four binary packages.
libxerces25
libxercesicu-25
libxerces25-doc
libxerces25-dev
libxerces25 and libxercesicu-25 are two versions of the runtime
libraries configured with different options. We may need to add a
third version as well. The -doc package (architecture-independent) is
just documentation. None of these packages are affected by this, so I
will not discuss them further.
The upstream xerces distribution does not generate a static library
and is set up in a way that would make this somewhat tricky to add, so
the -dev package does not contain one. The -dev package, in fact,
contains only one architecture-dependent file: config.status from the
build since this is needed to build libxml-xerces-perl.
My proposal would be to leave the runtime and -doc packages alone and
to replace the -dev package with three new packages:
libxerces25-dev
libxerces25-source
libxerces25-config
The -dev package would contain only what the upstream source package
installs. Since this does not include config.status, this has the
compelling advantage of making it architecture-independent, which is
good because it's about 850K. (I have verified this -- with the
exception config.status (and, trivially, changelog.Debian.gz), all the
rest of the files in the -dev package are identical across all the
architectures.)
The -source package would contain a freshly extracted upstream source
package. It could also be architecture "all". (It will,
unfortunately, be about the same size as the xerces25 source package,
just like the kernel-source binary package is almost as big as as its
source package.) The -config package would contain all the files in
the extracted source tree after configuration that are not present in
the source package. These packages would install into
/usr/src/xerces25 and would be architecture dependent and small. Most
likely, we can get away with only one instance of -config even though
we configure the xerces packages multiple ways, but the worst case
would be that there would need to be libxerces25-config and
libxercesicu25-config.
With this solution, a package that requires the full source for xerces
could build-depend upon -source or -config as appropriate, and a
package that builds against xerces in a normal way could just
build-depend on the -dev package. Since some packages, like
libxml-xerces-perl, depend on config but don't need anything else from
-source, it isn't necessary to make -config depend upon -source.
Something that needs a fully configured source tree
Does this seem like a good approach? Do you agree with my choices
about the names and install paths for the -source and -config
packages? Are there other packages that do this that I should look
at? I am aware of the kernel-tree-* packages, but I think the kernel
is enough of a special case that it's not necessarily correct to model
after it for this. Most of the -src and -source binary packages I see
are for kernel drivers. Most of them seem to be there to enable users
to build customized versions of things rather than to support other
packages to build against them. Those packages install a .tar.gz or
.tar.bz2 file into /usr/src rather than extracted sources, but a
.tar.bz2 file is not as useful as a build dependency because then all
dependent packages have to manually extract this somewhere.
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
Reply to: