[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging a difficult project



On Fri, Aug 03, 2007 at 07:46:44AM +1000, Brendon Costa wrote:
> I have a software project that I plan on creating Debian packages for
> which is quite different from many other packages in that it also 
> installs patched versions of GCC and Doxygen (That must not conflict 
> with existing installs of these programs).

> http://edoc.sourceforge.net/

> --- Project Description ---
> EDoc++ is a compile time C++ exception analysis/documentation tool.

> EDoc++ is a tool that analyses exception usage in C++ source code to
> provide compile time/static analysis checks similar to that found in
> other languages such as Java. EDoc++ can also generate detailed
> information about exception propagation in various formats. One of which
> can be used by doxygen in documenting exception information for API's.
> --- End: Project Description ---

> This project has a set of patches against GCC 4.0.1 that create a 
> "modified GCC" which exports data while compiling C/C++ programs. This 
> data is then used for performing source code analysis (In particular 
> analysing information relevant to C++ exception propagation).

Hmm, I would question whether this is something we'd want to include in the
Debian archive as-is; I think we already have way too many gcc packages
being carried around with our releases and that we need to try to make this
number go down, not add more copies of the gcc source code to the archive.

> The idea is that this patched GCC/Doxygen should be installed
> "alongside" existing GCC/Doxygen versions and should not interfere with
> them.

> Does anyone have suggestions as to how best I can tackle this problem in
> a way that would be considered acceptable for inclusion in debian? The
> current method works fine, but does not meet the debian policy requirements.

I would recommend that you look into the Debian diff for the gcc-4.1 source
package, to see how putting the version number into the binary name is
handled ("gcc-4.1", "cpp-4.1", ...).  The same could be done for edoc, which
would be policy-compliant.

Since gcc-4.0 itself is no longer part of Debian (except for libgcc2 on
hppa), you might even use the same naming scheme and have your package
Conflicts/Replaces/Provides gcc-4.0, cpp-4.0, g++-4.0, and anything else
needed.

> I plan on creating the following packages:

> edoc
> edoc-doc
> libedoc
> libedoc-dev
> libedocbfd
> libedocbfd-dev

> Would people suggest that the patched gcc/doxygen be included as part of
> a main: edoc package, or as separate packages called: "edoc-gcc",
> "edoc-doxygen"?

Given the aim of the edoc framework, I don't see any reason you would want
to split those into separate packages.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: