On Tue, 2007-11-06 at 17:23 +0900, John Summerfield wrote: > Ralf Corsepius wrote: > > On Tue, 2007-11-06 at 11:00 +0900, John Summerfield wrote: > >> Ralf Corsepius wrote: > >>> On Tue, 2007-11-06 at 08:00 +0900, John Summerfield wrote: > >>>> Ralf Corsepius wrote: > >>>>> On Mon, 2007-11-05 at 19:03 +0900, John Summerfield wrote: > >>>>>> The standard way in this case is to follow the supplier's advice:FSF in > >>>>>> this case. It should install to /usr/local, well out of your way and > >>>>>> defined by standards to be used this way. > >>>>> If you do this, you are replacing the "system compiler" with a local one > >>>>> (/usr/local is special to gcc!). You will rarely want to do this under > >>>>> linux. > >>>> It's true that installing binaries to /usr/local/bin makes it the > >>>> default compiler, but you do get to choose with your PATH settings. > >>>> > >>>>> Much less error prone is to install to a > >>>>> prefix != /usr and prefix != /usr/local. > >>>>> > >>>>> The LSB recommended way would be to install to /opt or a subdirectory > >>>>> thereof (e.g. --prefix=/opt/gcc42). > >>> BTW: FHS would have been correct (my fault). > >>> > >>>> /opt commonly seems to be populated with rpms. > >>>> I'd keep out of it: > >>> /opt is reserved for vendors. That's exactly what you act as when > >>> installing additional packages in parallel to the one the OS vendor > >>> installs. > >> > >> Bruce, the OP, was talking about doing this for his own use on his own > >> system. He's functioning as an administrator and not as a vendor. > > Nit-picking. The difference is moot. It doesn't matter who builds a > > piece of SW, whether he exercises "configure && make && make install" or > > installs a pre-built tar-ball or rpm. The result to his system is the > > same: A package is being installed. > > The difference is who manages it, and the scope of the problem, if any. Which, on the technical, side makes no difference. It doesn't matter "who" (admin, OS-vendor, 3rd party) nor "how" (rpm, tar what ever), nor whether some thing is being distributed. What matter is "what" == a package and "where" == how it cooperates with other pieces of SW (system integration). > FHS is at http://www.pathname.com/fhs/pub/fhs-2.3.html > > > FHS is, apparently, edited by three people: > Edited by > Rusty Russell > Daniel Quinlan > Christopher Yeoh > Copyright © 1994-2004 Daniel Quinlan > Copyright © 2001-2004 Paul 'Rusty' Russell > Copyright © 2003-2004 Christopher Yeoh > > The three are all famous in the Linux community, just ask Google if you > doubt me. Yes, and ... why are you arguing? It's a proposal/guideline/recommendation having been implemented by some intelligent people with some linux background. It's up to the user/admin/vendor to respect it or not - It's not a law, but it also would not be a mistake to respect it. Fedora tries to respect it, so users/admin also are better off respecting it. However, it's their liberty not to do so. > I would not expect Unix folk, with over 30 years' customary practice > behind them are going to change their ways just because the Linux people > say they should, do you? Nobody said the FHS is a law. Its a recommendation/guideline ... people are free to respect it or not. ... yes, many people disagree with details inside, and many admins and vendors prefer to obey their "grown customary standards". > gcc is never part of the OS. Oh no, not this ole' discussion again ;) Yes, this point is controversial. Some people don't consider a system-compiler to be part of the OS, other do. POSIX considers it an optional component of an OS's runtime envirionment. > Installing gcc under /usr/local has no implications for the ordinary use > of the system, software developers aside. Well, it has, because GCC comprises run-time libs. Install a gcc with an incompatible ABI/API to /usr/local, use it to compile, and you'll likely be watching your system going up in limbo. Ralf -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
