variant symlinks (was: Re: Anybody working on removing sendmail from base?)

Mike Porter mupi at mknet.org
Tue Sep 30 14:29:48 PDT 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 29 September 2003 08:14 pm, Justin C. Sherrill wrote:
> Matthew Dillon <dillon at xxxxxxxxxxxxxxxxxxxx> wrote in
>
> news:200309292118.h8TLIhbC018237 at xxxxxxxxxxxxxxxxxxxx:
> >     So, to begin this discussion lets consider how 'mtabase' is dealt
> >     with in the kernel?  I'll throw out a possibility:
>
> Who would be interacting with a framework like this?
>
> The people designing the operating system?

obviously this class.

> People creating ports that overlap the base system?

I thought the idea was to remove these bits from the base system, thus 
eliminating this class.  espcially for mtas, there is no need to have a 
'base' mta included, as long as whatever mta is installed provides certain 
base functions.  With a couple of tweaks, even that becomes unnecessary from 
a base standpoint.

Some of the other parts are a little more difficult to do without.  Perl and 
gcc, for example, which are used by the ports system and make world, for 
example.  Users willing to forgo ports and building world (or indeed, 
building a custom kernel) could get away with not ever needed a compiler 
installed. (and don't knock it, the OS with the greatest market share in the 
world, right now, comes with no compiler by default, to say nothing of 
'building a custom kernel'--NOT that I am in any way a supporter of that OS 
(OK, my 2 year old plays some games that don't (yet...) work under wine...), 
just pointing out that a very large segment of the market doesn't care if 
there is a compiler in the base system; if one is content with a genreic 
kernel, and installing only packages (which many times works better, and 
almost always is faster (to install, at least) than a port.

> Any port creator?

The idea is that any port creator would be able to take advantage of the 
framework.  Certain parts are very specific, for example, talking about mtas, 
there will be some work to be done in porting an mta to comply with our 
framework.  Ditto compilers/interpreters, which would have to be built to 
install into specifc locations, and would have some different handling rules 
when compared to the usual treatement of ports, e.g. during a 'make clean'.  
But any porter would be able to take advantage of using a dependency to a 
specific version of gcc to ensure a minimum amount of work in developing the 
port.  What I am getting at here is that there is a significant amount of 
work (if it is possible at all) involved in porting an application written to 
use gcc-3.4 to compile under gcc-2.95.4

> Users?

Again, the idea is that all of this is transparent to the user, so the user 
doesn't have to worry that installing qmail will break things, or, mroe 
significanlty, that every time he (re)builds world, he will have to reinstall 
qmail.  Or procmail.  Or Exim.  Or gcc.  Or perl.  Or <name of program>.

mike


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/efToY30jZzkECLcRAi2nAKCqBqpQXzT3irrdtBVALLxajLGYwwCdHmfF
4Xr37xHwuFdHei1gMw4LkFc=
=Rg0C
-----END PGP SIGNATURE-----







More information about the Kernel mailing list