Re: FreeBSD-like approach for Debian? [was: Re: Deficiencies in Debian]
Tuesday, September 14, 1999, 11:43:02 AM, Daryl wrote:
> i believe the major advantage in making a distinction between a base
> operating system and the applications it supports lies mostly in the
> modular design of such a system.
With the strength of the packaging system, however, the modularity is
maintained by the packaging system, not by the file system. If you were to
remove the packaging system I would be the first to agree. To state that you
must have a file system separation solely on the basis of modularity is to
ignore the packaging system entirely.
Debian is modular. This is why I challenge the whole notion of a "base"
OS. For example, is an MTA base? Most would say yes. Which one? Sendmail
is certainly the most popular in the 'nix world. So, for argument's sake,
let's stick that in "base" and thus into /usr/bin. Now, that makes the other
MTAs, smail, qmail, exim, postfix (did I miss any?) all "optional". If we
were to remove them and install, say, exim, that would mean that
/usr/bin/sendmail is lost and now we have /usr/local/bin/sendmail pointing to
/usr/local/bin/exim.
Things break.
In the current system then do not because it all goes in the "base"
because it was all packaged to go there. It was all integrated to work
together.
You're looking at modularity at the file system level, Debian is modular
at the package/program level.
Another quick example. vi. vi is originally linked to nvi (IIRC). Now,
install vim, uninstall nvi and try to run vi. You get vim because of the
alternates system. ex & view both get moved to vim seamlessly. Now remove
vim and type vi again. IIRC, this will run ae in vi emulation mode.
> much has been written about modular design, but essentially it allows for
> parts of a system to be easily added, deleted, or moved with minimum impact
> or dependencies, allowing for the greatest flexibility.
Given my two examples and my limited experience with the inner workings of
Debian, can you really say that what is given now *isn't* very modular and
easy to have parts added, deleted and moved?
> it was my job to integrate internal and 3rd party software applications for
> distribution throughout sun's wide area network (swan). we found that
> keeping (as much as possible) the application's resources under one tree
> made managing that package much more efficient.
Traditional versus the Debian way.
> preferences, but that is probably true on both sides of the fence, as it
> where. in my experience it has just been easier to manage things when they
> are not strewn about all over the place.
Easier to manage things when they're not strewn all over the place. So
you want /bin, /sbin, /lib, /var, /usr, /usr/bin, /usr/sbin, /var/local,
/usr/local, /usr/lib, /usr/local/lib... *pant, pant*... /opt,
/opt/{package}/bin, /opt/{package}/lib, and, finally, /etc... and
/usr/local/etc.... Wait, isn't there one in /opt, too? Rats, forgot
X/Openwin...
I dunno about you, but that is the very definition of "spread out"
especially when you consider that {package} in /opt can be quite a few. I'm
disgusted with my path on my Solaris box at work. I needed to add
/opt/gnu/gimp/bin, /opt/gnu/gcc/bin and /opt/netscape to my path just to get
things to run which should have been, to me, in what is in my path in the
first place.
> i have often removed software packages, only to find vestiges still existing
> in different directories, a library in /usr/lib, or docs in /usr/doc, a
> config file in /etc, and so forth.
In the Debian manner of things I rarely find that to be the case. Well,
except for those pestering directories.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
Reply to: