DragonFly kernel List (threaded) for 2003-09
Re: Anybody working on removing sendmail from base?
-----BEGIN PGP SIGNED MESSAGE-----
On Monday 29 September 2003 08:25 am, Justin C. Sherrill wrote:
> Instead of worrying about what path is being taken, and so on, it may be
> better to keep the system compiler, languages, etc. completely hidden from
> the user, perhaps with the VFS material Matt is talking about. i.e. a
> system that has not had the gcc/tendra/Intel compiler port installed has no
> compiler at all, as far as the user is concerned.
> Otherwise, you could have each port developer trying to coordinate their
> port compiling with both the 'shipped' system compiler plus whatever is in
> ports, which may be changing. It would be helpful to remove one of those
> from the equasion. This carries through to other software that people
> upgrade or change - Perl, sendmail, shell, etc.
I'm sorry but this seems counterproductive. If there is going to be a perl
and a cc on the system, even if it is old an outdated, it is a waste of
bandwidth to force users to install one. Especially in the case where you
are installing, say, a gcc, which is exactly the same as the system version.
This wastes bandwidth for the installation process, as well as disk space in
having two of the same program installed. In addition to that, it doesn't
help to resolve the issue where user A wants one version, and user B wants a
I really like the suggestion of variant symlinks (that particular thought had
never occurred to me in suggesting the use of a wrapper), since that can make
cc directly dependent on the environment, and by correctly setting the
environment in a Makefile, you can force whichever version you need (although
the case could exist where you try to specify a non-existant (or
non-installed) version, and logic should be provided to deal with that, if it
is going to be truly transparent). It would even allow (although I am not
certain why we might want to do this, but we could, in fact if we wanted to)
a gradual migration of the system compiler to a different version, as the
makefiles for the various parts of the system could eaily be updated to use a
newer version of gcc (assuming there is a good reason to do this, such as
faster code execution or better optimization from the newer version), without
affecting the rest of the system. As bits and pieces of the system get
upgraded to use the newer versions, eventually, the whole system would be
compiled using the newer version....just a random thought--probably not a
very good one at that, since it makes a buildworld dependent on more than one
version of cc...
the whole point of the exercise (i thought) was to make it so that a porter
(aka port developer) does not *need* to try to make a program that was
written for gcc 3.4 compile on gcc 2.95.4, which happens under FBSD. You can
use a port dependency to ensure that gcc 3.4 is installed on the system,
without worrying about the installation interfereing with the system's use of
2.95. Ditto with perl. This would greatly reduce the amount of patching
necessary to make a port work, and a lot more programs would 'just work'
right our of the box, without needing any patching at all. If porting is
easier, logic suggests that more programs would tend to be ported, becuase
each porter could do more programs, and more people could do porting. Can
someone explain why THAT is bad?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
-----END PGP SIGNATURE-----