Re: Proposal: cross-compiling / development packaging guidelines

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

 



Ralf Corsepius wrote:
On Wed, 2007-02-21 at 16:26 +0100, Hans de Goede wrote:
<snip>


The default for GCC is ${prefix}/$(target)/{lib|include}. This default is almost impossible to change.


I'm glad the things I "came up" with, closely match how you do things, thats good to hear and for me a confirment that I'm on the right track.

5) Docs (manpages, info and docs under %doc) will not be installed as they
    will be identical to the native version docs,

What you say only partially applies to gcc/binutils/gdb. Their section 3
man-pages are canonicalized (they install as <target>-manpage), hence
are free of conflicts with a native gcc. section-7 man-pages and infos
however conflict.


Okay, so since the are installed as <target>-manpage, they won't conflict, but will they contain any different content? I see no difference between "man arm-linux-as" and "man as", since there is no difference is it worth installing the same manpage twice, I know that one might only install the cross-toolchain and not the native one, but then we will be missing the section 7 manpages, info files etc already, and what are the changes of someone actually objecting to installing the native toolchain (even if just to get the docs)?


This is the classical standard GCC wrapper approach for non-multilib'ed cross-toolchains.


So even more agreement good to hear :)

8) The SRPMS for all these packages will most of the time contain the exact
    same tarbals as the native binutils / gcc / libs

    Possible solutions:
    a) Live with the extra diskspace / bandwidth cost this induces upon
       our mirrors
That's what I'd do.

An alternative would be to build different versions inside of the same
SRPMS at one time.


That would require coordination between the cross-compile stuff maintainer and the native maintainer, also that would force a rebuild of both native and cross compile stuff if one of the 2 changes. I thought of this too but I don't see this as a very realistic option.


Regards,

Hans

--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list

[Index of Archives]     [Fedora General Discussion]     [Fedora Art]     [Fedora Docs]     [Fedora Package Review]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite Backpacking]     [KDE Users]

  Powered by Linux