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]
