cleanup-boot.messages+overhaul-install
Joshua Tinnin
krinklyfig at spymac.com
Sat Apr 30 04:26:10 PDT 2005
On Sat 30 Apr 05 03:27, "/dev/null" <null at dnswatch.com> wrote:
> Another thing I *really* hate, is
> not knowing that installing this Word Proccessor will start this
> chain that ultimately installs an additional 750MB of Gnome $#it that
> I have absolutely no use for, and additionally installs another 350MB
> of Multimedia and related Sound servers, daemons on my system, when
> there isn't even a PC speaker hooked up to the thing. SO, I'd really
> like to figure out a better way to handle ports - both through
> Sysinstall and *hopefully* through ports as well.
I empathize with your frustration, but this is not an issue with
FreeBSD, it's an issue with the way large desktop suites like Gnome
handle dependencies. It's the same with KDE, and it's true whether or
not you're installing it on FreeBSD, Slackware, Solaris or what have
you. The concept behind these suites is that it should provide
everything a "typical" desktop user would need, and everything is more
or less bundled together - true, this concept originates with the
Mac/Windows approach (more the latter), and I understand why people are
loathe to accept such a concept on a *nix system, but in truth these
desktops have accomplished higher adoption rates than would be possible
otherwise, and they do contain many useful tools. And, honestly, that
concept is also what's driving your proposal.
I'm not sure if you'd ever be able to change this, as the concept is
driven by the respective projects' overarching philosophies.
Personally, I'd *love* to be able to install KMail without having to
install kdebase and kdelibs, not to mention the rest of kdepim, but
trying to convince the KDE project to uncouple it from the rest of the
project is rather like tilting at windmills. That being said, it would
be helpful in some circumstances to know exactly what will be pulled in
by installing a part of one of these suites (i.e., most of the rest of
the suite, or at least its base and libraries), but that is already
possible, if not readily apparent to a new user.
There are dependencies which are pulled in by large ports which
sometimes do not need to be there to install the original needed port
(dependencies recursing in odd directions), but in general ports does
work very well for the large number of projects within it, and it does
so without being needlessly complicated, though it does contain a lot
of complexity. It does have some flaws, but the fact that it simplifies
recursive dependencies (as much as it's allowed), and the ability to
tailor individual aspects of it to my own needs through changing
Makefiles and patches locally, is what keeps me using it. Local
compilation allows for so much, but it can be needlessly complex, and
ports makes all the parts come together, most of the time without
issue, but if there is an issue it usually can be fixed. Plus, I plain
like to compile apps locally ... call me crazy (wouldn't be the first
time ;)
Just give me the tools and don't put a hood over the engine, I can
handle the rest, which seems to be what drives FreeBSD and attracts
people to it, and it's why I keep using it.
- jt
More information about the freebsd-current
mailing list