Packaging a difficult project
Hi all,
I was directed here from debian-mentors with my question.
--- Original Post ---
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).
Much of the project is easy to break into separate packages, I.e.
creating separate packages for the libs, apps and dev environments.
However the patched versions of GCC and Doxygen that are also required
by EDoc++ can't be installed in standard locations as they may conflict
with existing installed GCC and Doxygen.
The idea is that this patched GCC/Doxygen should be installed
"alongside" existing GCC/Doxygen versions and should not interfere with
them. Currently if the EDoc++ project is configured and built as shown
below:
./configure --prefix=/usr &&
make &&
make install
Then the EDoc++ specific apps, libs etc are installed as expected into
/usr/bin, usr/lib ..., however the patched version of GCC and Doxygen
are installed to: /usr/edoc_patched/bin, /usr/edoc_patched/lib ...
When EDoc++ is configured and built, the patched source for GCC and
Doxygen are currently configured with a prefix like: gcc/configure
--prefix=${prefix}/edoc_patched
I have been thinking of setting the GCC & Doxygen prefix values to one
of: $bindir/edoc_patched, $datadir/edoc_patched or
$libexecdir/edoc_patched instead of $prefix/edoc_patched. I think the
important thing to note here though is that they can't have their prefix
the same as that of the "normal" programs i.e. /usr, otherwise there is
a chance of conflicts between patched and non-patched GCC/Doxygen.
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 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"?
Thanks,
Brendon.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a difficult project
Thanks for the response.
>
> 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.
>
Unfortunately including the GCC source is very difficult to avoid for
this package. I have had thoughts about trying to use GCC GEM (Which is
not in debian from what i can see) to implement the data analysis and
export as a "GCC Plugin", however that is a large undertaking and I am
not sure that GEM is well maintained. It would also require a special
GEM patched GCC to be installed as another package anyway.
Before undertaking the process of building the packages in a policy
conforming way, is it possible to know if there is much likelihood of
the packages being included in Debian?
>> 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.
>
Thanks for the tip. Would it be fine to use a format similar to that
used by cross compiler packages? E.g: "edoc-g++" This would also include
a directory /usr/edoc A similar package for comparison would be: mingw32
The mingw32 package installs i586-mingw32msvc-g++ ... and also has a
directory: /usr/i586-mingw32msvc/bin ...
Would this be considered suitable? If so is there any reason why some of
the i586-mingw32msvc-* binaries for the mingw32 package have hardlinks
into the /usr/i586-mingw32msvc/bin/ directory and others do not?
I would prefer to have hardlinks for all the binaries prefixed with
edoc-* if i were to format my package like this. Since it should be
possible for a user to set PATH and LD_LIBRARY_PATH correctly and build
from the /usr/edoc/bin/ directories without requiring build tool prefixes.
> 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.
The difficulty is that it is not really the same as GCC 4.0. It behaves
a little differently, uses much more memory and takes longer to compile.
I would not wish users to use the EDoc++ modified GCC without explicitly
knowing that they are doing so.
Thanks for the comments. I appreciate the help as this is my first
experience working with debian packages.
Brendon.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a difficult project
> >> I believe that edoc doesn't use the code generator, only the front >> end, so it doesn't need care from port maintainers. > The GCC modification attempts to change as little in the GCC framework as possible and just performs analysis on the data structures generated by GCC as it compiles code. As such GCC still generates binaries. In fact one of the data output formats (Which I assume will be the most commonly used output format) for EDoc++ is to embed the EDoc++ specific data into the binary files generated by GCC in an .edoc section in the binary file (Which is later accessed using libbfd). This makes locating data for post processing a much easier task. As such the EDoc++ patched GCC still generates binaries and so it does not just include the front end. However I have made it plain that to use the resulting binaries is done so at the users risk as I can not guarantee the integrity of the resulting binary files, simply because I lack the man hours to do this. However with that said I have been using them myself and not encountered any problems. Also I am unable to maintain various system specific patches for GCC such as Debian, Fedora, NetBSD etc. Though I am not sure if these systems currently require platform specific patches from the existing GCC sources. > Which was not my objection. I understand and accept that edoc might not be > a very good compiler to use on all architectures, and don't think that > should be a reason to keep it out of the archive; my concern is that, > depending on which binary packages it needs to build, edoc could take up as > much as 1GB of space on our full mirrors, for something that should > effectively be a patch against gcc. > EDoc++ binaries are currently around 20M. It does not require any special binutils etc, but will just use what is already available for the system. I am currently building a single non-policy conformant .deb package. Brendon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a difficult project
Thomas Jollans wrote: > On Saturday 04 August 2007, Brendon Costa wrote: >> EDoc++ binaries are currently around 20M. It does not require any >> special binutils etc, but will just use what is already available for >> the system. I am currently building a single non-policy conformant .deb >> package. > > I think the concern is more about the edoc source, which would apparently > include gcc source, which is large and already on the mirrors multiple times. > The tarball of all source necessary to build EDoc++ is 25M and extracted it is: 47M. EDoc++ stores in its source tree patches against GCC along with the GCC original tarballs, and at build time will extract the gcc tarballs into the build directory and apply the patches before building it. This means the builddir can be quite large, but all files in it are "derived" from the ones in the source directory and can be deleted between builds without any re-percussions. I am not sure where the 1G comes from, unless talking about the duplicity across various mirrors. I do admit however that there is an unfortunate problem that various projects may require GCC sources (Cross compilers are not an exception). This is unfortunate, however from what i understand it is unavoidable. If there is a way to avoid it I would be interested in looking at pursuing that option if it will help. Thanks, Brendon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a difficult project
Steve Langasek wrote: >> I am not sure where the 1G comes from, unless talking about the >> duplicity across various mirrors. > > No, this is an estimate based on the actual usage of pool/main/g/gcc-4.1 on > current Debian mirrors. (12 archs * 3 versions * n binary packages) > > Your note on the size of the edoc binary package would give a smaller total > than 1G, but AFAICS it would still be a rather large, rather niche package. > Yes that is true. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
