Re: seeking resolution to issues I have raised
On Tue, Mar 06, 2001 at 02:39:56PM -0800, Sean 'Shaleh' Perry wrote:
> On Tue, Mar 06, 2001 at 10:38:53PM +0000, Colin Watson wrote:
> >
> > So - reassigning the lintian bug about this to policy.
> >
> > Am I right in taking from the above that /usr/${arch} is essentially a
> > miniature mirror of the /usr filesystem? They certainly seem to have
> > similar structures. Thus, /usr/lib/${arch} or /usr/${arch}/lib or
> > whatever seems incorrect, and something at the same level as /usr/local
> > makes sense.
> >
> > I propose that we should override the FHS on this one. This is exactly
> > the reason we maintain the flexibility to do so.
> >
>
> My reading of the FHS yielded no good answer here. They seem to ignore it
> completely. Personally I do not care where it ends up, as long as we define
> a place where all cross-compiler items belong.
>
> Simply codifying current practice seems the best bet.
Please.. And I submit it be useful to decide to change dpkg-cross'
'crossbase' paramater (in /etc/dpkg/cross-compile) to correspond to the
same place as everything else.
Current practice has the compiler in /usr/blah (gcc-m68k-cross), and the
'imported' foreign-arch packages in /usr/local/blah (dpkg-cross).
Also, I DO have a fairly rough script for the automagic building of a
cross-compilation environment from sources and foreign-arch debs, but
the current lack of standardisation caused me to shelve it for the time
being. As soon as we come to some kind of consensus here (codifying
existing practice OF /usr/blah, or as was suggested to me privately a
few months ago, /usr/lib/blah instead) I will resume work on my script
and then formally ask someone to sponsor me.
-- Ferret
Who is still unable to grok binutils' rules file in an attempt to apply
it to gcc for building a recent compiler. gcc 2.8 is not recent enough
for a 2.4 kernel.
Reply to: