DragonFly kernel List (threaded) for 2003-09
variant symlinks (was: Re: Anybody working on removing sendmail from base?)
-----BEGIN PGP SIGNED MESSAGE-----
On Monday 29 September 2003 08:14 pm, Justin C. Sherrill wrote:
> Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote in
> > 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
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>.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
-----END PGP SIGNATURE-----