Port dependencies

[Polytropon]

On Fri, 01 Apr 2011 16:58:04 -0700, Chris Telting <christopher-ml at telting.org> wrote:
> Just in a thoughtful mood and thought I'd to the question to the cloud.

Oh the joy of cloud computing, erm... discussion. :-)



> One of my biggest gripes with the ports system is dependency hell.  
> Ports link against so my optional components and pull them into the 
> install.  Libraries and components are built based on make file 
> defines. 

If you do install a program via pkg_add (it's about
precompiled binaries, so no Makefile involved, not
even a ports tree), there are also means to determine
if something ELSE is needed - as a dependency. Hard
disk space is cheap today, so 99% of users don't even
bother installing all the stuff they primarily won't
need, but the program THAT they need insists on it.



> But this doesn't have to be so.  It's possible and easy enough 
> to check a running system for which libraries are installed and only if 
> a feature is enabled to load the library. 

It already works that way. Say program A needs B of version
n as dependency, then B(n) has to be installed even if
B(n-1) is already present on the system. This is no big
deal if B isn't installed at all, but requires caution
when it is (at version n-1). Of course, B may have other
dependencies that do not matter to A, but to B, so even
C(m) gets installed.



> The number of console 
> programs that want to pull in X window or kde is my boggling. 

Hmmm... The only one I remember being that way is the
old cvsup, but there was nocvsup-nogui (or -nox11?).



> Knowing 
> how to program myself when I see a "make config" menu on every single 
> port it makes me want to cry. 

You can script those mechanism, so you get rid of that
interaction and can use file-defined settings.



> I think the "make config" menus should 
> have everything checked by default and only be provided to prevent 
> things from being compiled such as for embedded devices.

Oh no, please - NO! Everything checked by default? That
would be problematic for those who, for example, don't
WANT to use HAL+DBUS because it just doesn't work for
them. Or people who have security concerns (or maybe
even external regulations) so they do not want to install
something. And remember: Regarding codecs for mplayer
and mencoder, it's illegal to listen to MP3 in the US! :-)



> My question is why is this so?  Why can't programs do more run time 
> configuration?  Is a configuration run time system library needed to 
> make it easier?

You're bringing up an interesting idea, but runtime
detection of library (or feature) availability seems
to be very time consuming to me. An example is mplayer.
On older system, I did always compile it to match the
CPU that is present, means NO "runtime CPU detection".
Why? Because it often runs too slow on older system if
enabled.

And let's assume another typical example from  the
multimedia sector. You have installed mplayer and want
to play MP3 audio or an MPEG video file, or even a
DVD - which is completely illegal in the US. :-)
But there is no libdvd installed, and no MP3 codecs
for playing or encoding. What should happen? Upon
first start, should the program request you to
download and install them? But what if the system
is offline? I would assume it's better to install
all the stuff needed at install time, no matter if
being from ports or as a package.

The problem with packages is that most ports have
so many options that it would result in 2^x packages
if the port has x options. And how should the ports
then be named? Should the selected options be
abbreviated and in alphabetical order?

Well, I would REALLY like to have a USABLE set of
options predefined and compiled into the packages.
I know that this may very problematic (see codecs),
and the packages usually are made using the DEFAULT
options which may not be the OPTIMAL options for
everyone. And sometimes, there even isn't a package
(e. g. OpenOffice) with the required set of options,
and even if it is, half of the stuff one assumes is
missing (also see OpenOffice).

So there is still stuff one needs to compile, and
YOU are in charge to define the options you need.
This is the "downside" when you're running a multi-
purpose OS like FreeBSD.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...