unless someone can show me policy or similar established
> practice to back this up, I'm closing this one too. See the advice
> above. Closes: #165848
This is how tpkg-make, uclibc-toolchain, and all known (to me)
previous incarnations of cross compilers in Debian work.
dave...
--- End Message ---
On Sat, Feb 03, 2001 at 10:52:54AM +0100, Marco d'Itri wrote:
> On Feb 03, [EMAIL PROTECTED] wrote:
>
> >What workable alternative would there be to using
> >/usr[/local]//(bin|lib|include)?
> /usr/lib//...
So just to make sure by example:
/usr/lib/sparc-linux/bin/
...
nm
ranlib
ar
as
ld
...
/
On Feb 03, [EMAIL PROTECTED] wrote:
>What workable alternative would there be to using
>/usr[/local]//(bin|lib|include)?
/usr/lib//...
--
ciao,
Marco
On Fri, Feb 02, 2001 at 01:49:01PM -0800, Sean 'Shaleh' Perry wrote:
> lintian currently emits a tag for cross-compilers because they make a
> directory
> in /usr's top level for TARGET i.e. /usr/m68k-linux.
>
> The FHS states:
>
> No large software packa
lintian currently emits a tag for cross-compilers because they make a directory
in /usr's top level for TARGET i.e. /usr/m68k-linux.
The FHS states:
No large software packages should use a direct subdirectory under the
/usr hierarchy. An exception is made for the X Window System becau
).
Did the standard commitee consider cross compilers at all, and is the
recommended place in the file system somewhere below /usr/lib, or:
Did you simply "forget" about cross compilers and didn't consider them to be
of much relevance. In this case it might make sense to mention t
ctice." I'd say the same
> > > is true of cross compiling environments.
> >
> > I'd say it isn't, because the fsstnd doesn't exempt it.
>
> But then, a cross compiler setup is not really a "software package", so I
> think the
oss compiling environments.
>
> I'd say it isn't, because the fsstnd doesn't exempt it.
But then, a cross compiler setup is not really a "software package", so I
think the paragraph in question doesn't apply to cross compilers.
I think the committe just didn'
Martin Mitchell wrote:
> Indeed, and if you note the last point, the X Window System is excepted due
> to "considerable precedent and widely-accepted practice." I'd say the same
> is true of cross compiling environments.
I'd say it isn't, because the fsstnd doesn't exempt it.
> Rather than do thi
Joey Hess <[EMAIL PROTECTED]> writes:
> I think you may be reading too much into the word "large". The complete
> paragaph:
>
> No large package (such as TeX and GNU Emacs) should use a direct
> subdirectory of /usr. Instead, there should be a subdirectory within
> /usr/lib (or /usr/local/
Santiago Vila wrote:
> No large software packages should use a direct subdirectory under the
> /usr hierarchy. [...]
>
> I think that a cross-compiler is not a "large" software package like the X
> Window System.
I think you may be reading too much into the word "large". The complete
paragaph
On 05-Apr-99, 05:52 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote:
> These packages are cross-compilers and the paths they use are
> currently derived from the cross-compiler guidelines in gcc's INSTALL
> document (by just replacing /usr/local by /usr).
I tend to agree
I forgot to Cc this to -policy, here is my reply:
> Santiago Vila <[EMAIL PROTECTED]> writes:
>
> > I think that a cross-compiler is not a "large" software package like the X
> > Window System.
>
> I agree. It also fits in with the goal of having /usr read only. The FSSTND
> also mentions the X
[ Moving to -policy ].
Lintian warns about the use of /usr/i386-gnu as a non-standard directory
in the gcc-i386-gnu package I maintain, and it also warns about the use
of /usr/m68k-linux in the gcc-m68k-linux package maintained by Martin
Mitchell.
These packages are cross-compilers and the paths
14 matches
Mail list logo
