Re: gcc install/upgrade question

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

 



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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux