Port dependencies

[Chris Telting]

On 04/01/2011 17:51, Polytropon wrote:
> 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. :-)
Wasn't that the a subplot of the hitch hikers guide?  That the sum of 
human consciousness is just a cloud computer?  New term, old idea.

>> 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.
Ports or packages, what I'm discussing is minimizing dependencies.  I 
compile my own packages and use them across all my computers.

What I'm saying I'd like to see is minimal installs.  If you need a 
feature like for instance LDAP or SQL then you need to install that 
port.  Need another feature? Install yet another port.  The program 
should detect that new programs/libraries are available or at a minimum 
enable them though uncommenting a line in a conf file.


>> 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.
And that's the mess I don't like.  It's like the six degrees of 
separation rule.  Installing one application sometimes means installing 
100 other ports/packages with features the average user has no need or 
interest in yet.  I'm just saying we should have to need to 
install/compile all those packages when we don't need them and we should 
have to need to recompile ports just to add a new capability.

>> 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?).
Well I decided I wanted to try to setup pulseaudio as a network sound 
server on a headless computer and it pulled in X.  Sure I could 
recompile just for that one computer.  But that isn't elegant.  The 
storage space doesn't matter.  What annoys me is the installation time 
and the longer compile time as well as to some extent downing time.

> 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! :-)
The point would be that the programs wouldn't have those features 
enabled by default, you have to configure them or the program can 
auto-detect.
>> 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.
Well obviously that one actual good reason for people to compile their 
own ports.  Nothing can change that.  What I'm saying is that libraries 
and features shouldn't be in the config menu.

> 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.
If it worked like like would like then you wouldn't be able to play 
those files unless you downloaded another package or compiled the ports 
for the mp3 library.  Same as it works on windows.  Don't have a codec.. 
then you need to install one...

> 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.
See above.  What I want to see is minimal installs with all features 
being usable once you install the optional components.  And run time 
detection for programs shouldn't be all that difficult or computation 
intensive.  The program would just consult pkg_info or another similar 
but faster database (and maybe somewhat platform independent) of what's 
installed on the system.


Chris