Re: Port dependencies
On Sat, Apr 02, 2011 at 08:07:25PM -0700, Chris Telting wrote: seriously, this is why i want that debian+freebsd that was discussed recently. the kernel is ours and number one in the world. and the ports stuff is basically packages that more/less just-work. you can get the src =with= the pkg. How does debian get around all the make config options that we deal with? Such as does such and such package pull in samba... Or does debian just compile with every option more or less enabled? Chris not sure about setting the options for a particular port, but i think you can build it with various flags set when you pull down the src. at any rate, since most drives are HUGE these days, enabling all/most options doesn't eat up that great a percent of the disk. and yeah, that's just my guess. note that i've been using freebsd since '95 and linux since '05. -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix Journey Toward the Dawn, E-Book: http://www.thought.org The 7.98a release of Jottings: http://jottings.thought.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
2011/4/3 Chris Telting christopher...@telting.org: seriously, this is why i want that debian+freebsd that was discussed recently. the kernel is ours and number one in the world. and the ports stuff is basically packages that more/less just-work. you can get the src =with= the pkg. How does debian get around all the make config options that we deal with? Such as does such and such package pull in samba... Or does debian just compile with every option more or less enabled? Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD's kernel, coupled with the regular Debian package set. from http://www.debian.org/ports/kfreebsd-gnu/ So it seems they basically use their own packages and not the ports. Romain ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
On Sun, Apr 3, 2011 at 5:07 AM, Chris Telting christopher...@telting.org wrote: How does debian get around all the make config options that we deal with? Such as does such and such package pull in samba... Or does debian just compile with every option more or less enabled? Yes, and no. One debian source package may create 1 or more binary packages. For instance, Debian has at least two sudo packages (sudo and sudo-ldap) -but only one source package. Take a look here: http://packages.debian.org/squeeze/sudo (Also, Debian/Ubuntu also create -dev packages for headers and development libraries, which FreeBSD ports does not (THANK GOD!)) -- chs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
Op 2-4-2011 19:03, Randal L. Schwartz schreef: That's one of the first things I do with a fresh system that will be only a server: echo WITHOUT_X11=yes /etc/make.conf And then *never* use packages. Only ports Are the quotes neccessary? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
On Sat, Apr 02, 2011 at 05:07:54PM -0700, per...@pluto.rain.com wrote: Chris Rees utis...@gmail.com wrote: On 2 April 2011 00:58, Chris Telting christopher...@telting.org wrote: One of my biggest gripes with the ports system is dependency hell. I think you've misunderstood the term dependency hell [1]. Anyone who has spent hours struggling with rpm ... would never dare to even think of such terms when using the Ports Collection. Dependency purgatory? I'd say it's something more like dependency real-world. Purgatory would be Ubuntu, where installing something with Synaptic doesn't require you to track all the (recursive) dependencies yourself, but uninstalling Evolution can break the whole system because of the insanely inclusive dependency policies for packages. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpfSWO25iwLE.pgp Description: PGP signature
Re: Port dependencies
On Sun, Apr 03, 2011 at 10:35:08AM +0200, Romain Garbage wrote: 2011/4/3 Chris Telting christopher...@telting.org: seriously, this is why i want that debian+freebsd that was discussed recently. the kernel is ours and number one in the world. and the ports stuff is basically packages that more/less just-work. you can get the src =with= the pkg. How does debian get around all the make config options that we deal with? Such as does such and such package pull in samba... Or does debian just compile with every option more or less enabled? Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD's kernel, coupled with the regular Debian package set. from http://www.debian.org/ports/kfreebsd-gnu/ So it seems they basically use their own packages and not the ports. Romain Well, so then _this_ is ho w thei r stuff works together. It is all from the deb packages. gary Ps: i'm glad i quit porting our libc to the gnu world back in 199[?]. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix Journey Toward the Dawn, E-Book: http://www.thought.org The 7.98a release of Jottings: http://jottings.thought.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
Dick == Dick Hoogendijk d...@nagual.nl writes: Dick Are the quotes neccessary? No. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
On 2 April 2011 00:58, Chris Telting christopher...@telting.org wrote: Just in a thoughtful mood and thought I'd to the question to the cloud. One of my biggest gripes with the ports system is dependency hell. I think you've misunderstood the term dependency hell [1]. Anyone who has spent hours struggling with rpm (ugh, or worse CMMI) to get x application installed which depends on y from z.alpha.com and s from t.beta.com, which also need rpm-ing with their own dependencies would never dare to even think of such terms when using the Ports Collection. I found it a miracle when I first moved! Chris [1] http://en.wikipedia.org/wiki/Dependency_hell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
On 2-4-2011 2:51, Polytropon wrote: 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. That is a good thing. But I remember an issue that I never understood. I onced set up a system as a mail and webserver and used packages for this. Fast and easy I thought and good enough. But although lamp/famp/samp is very common I could not install apache WITH php support. Why? Because php has no support for apache compiled in the precompiled package (it might have been the other way around; not quite sure). Anyway, apache+php could not be installed from packages. I had to compile them from ports. I hated that and could not understand why a so common setting is not on by default. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
Chris Telting wrote: 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. It's not a minimal install if binaries are bloated with extra code to selectively enable _all_ functionality depending upon run-time configuration options and dependency detection, rather than just the functionality that is going to be used. And build times would be longer, usually much longer, because all functionality in the software and all possible dependencies would have be built. And of course a lot of software would have to be rewritten. And I think that the added overhead would not always be negligible. So while your idea has certain advantages, it also has disadvantages. It does not seem practical to implement it, even if it were desirable to do so, for most software at the present time. b. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
Matt == Matt Emmerton m...@gsicomp.on.ca writes: Matt Every time I see a webserver with X11 on it, it's because of these two. Of Matt course, using ghostscript*-nox11 as well as setting WITHOUT_X11=yes solves a Matt lot of this mess, but on a system that's already been infested, it's Matt easier just to rebuild from scratch. That's one of the first things I do with a fresh system that will be only a server: echo WITHOUT_X11=yes /etc/make.conf And then *never* use packages. Only ports. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
On Fri, 01 Apr 2011 21:36:55 -0700, Chris Telting christopher...@telting.org wrote: On 04/01/2011 17:51, Polytropon wrote: On Fri, 01 Apr 2011 16:58:04 -0700, Chris Teltingchristopher...@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. Basically, yes. The computer IS a(nother) world. 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. I would like that, too - modularity on the basis of precompiled packages. The problem would be the integration of features on runtime base, as you correctly mentioned. Metaports or metapackages could be used to define common configurations, e. g. mplayer + mencoder with OSD fonts and all the codecs or OpenOffice with german localization, no KDE, no Gnome, no CUPS, but with dictionaries. That would be very nice to have. The program should detect that new programs/libraries are available or at a minimum enable them though uncommenting a line in a conf file. I would say config file (maybe with good defaults) would be a good approach. I'm somewhat suspicious about all the autodetect magic, because in worst case, it just doesn't work, or is unpredictable. 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 difference is we need vs. the program needs. Some requirements are obvious (e. g. a Gtk program needs Gtk libraries), but others are debatable (e. g. the Gtk File Open... dialog defaults to incorporating SAMBA libraries, but if you're not going to use that, _you_ will have no use for them). Well I decided I wanted to try to setup pulseaudio as a network sound server on a headless computer and it pulled in X. Yes, that's a good example. Others have already mentioned that certain typical server functionality also may incorporate X or at least some of its components - on a server that doesn't have a GPU and run any X functionality. Sure I could recompile just for that one computer. But that isn't elegant. The storage space doesn't matter. It's just the most used argument. :-) What annoys me is the installation time and the longer compile time as well as to some extent downing time. Well, that's worth mentioning, but the reply would be: You have two systems in parallel, while one installs, the other one runs. :-) But I see your point. 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. So THAT would be understandable - config file is often better, or maybe a hierarchical desision: if config file is present, use it; if not, try to autodetect. 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... As I mentioned above, a typical use or full-featured metaport or metapackage would be good; just imagine you could pkg_add -r mplayer-full and it would install ALL the codecs, as well as the mencoder part, without any further questions or interactions. On the other hand, the simple default port would install with minimal requirements (in regards to dependencies), which could also be very useful in certain cases, especially when the government wants it that way. :-) 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. Understood and seconded: It sounds like an interesting approach. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
Chris Rees utis...@gmail.com wrote: On 2 April 2011 00:58, Chris Telting christopher...@telting.org wrote: One of my biggest gripes with the ports system is dependency hell. I think you've misunderstood the term dependency hell [1]. Anyone who has spent hours struggling with rpm ... would never dare to even think of such terms when using the Ports Collection. Dependency purgatory? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
On Apr 2, 2011, at 7:07 PM, per...@pluto.rain.com wrote: Chris Rees utis...@gmail.com wrote: On 2 April 2011 00:58, Chris Telting christopher...@telting.org wrote: One of my biggest gripes with the ports system is dependency hell. I think you've misunderstood the term dependency hell [1]. Anyone who has spent hours struggling with rpm ... would never dare to even think of such terms when using the Ports Collection. Dependency purgatory? Dantency Inferno. :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
On Sat, Apr 02, 2011 at 07:45:06PM -0500, Ryan Coleman wrote: On Apr 2, 2011, at 7:07 PM, per...@pluto.rain.com wrote: Chris Rees utis...@gmail.com wrote: On 2 April 2011 00:58, Chris Telting christopher...@telting.org wrote: One of my biggest gripes with the ports system is dependency hell. I think you've misunderstood the term dependency hell [1]. Anyone who has spent hours struggling with rpm ... would never dare to even think of such terms when using the Ports Collection. Dependency purgatory? Dantency Inferno. :) seriously, this is why i want that debian+freebsd that was discussed recently. the kernel is ours and number one in the world. and the ports stuff is basically packages that more/less just-work. you can get the src =with= the pkg. . ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org -- Gary Kline kl...@thought.org http://www.thought.org Public Service Unix Journey Toward the Dawn, E-Book: http://www.thought.org The 7.98a release of Jottings: http://jottings.thought.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
seriously, this is why i want that debian+freebsd that was discussed recently. the kernel is ours and number one in the world. and the ports stuff is basically packages that more/less just-work. you can get the src =with= the pkg. How does debian get around all the make config options that we deal with? Such as does such and such package pull in samba... Or does debian just compile with every option more or less enabled? Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
On Fri, 1 Apr 2011, Chris Telting wrote: 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. 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. Port Makefiles already have BUILD_DEPENDS, RUN_DEPENDS, and LIB_DEPENDS, which do this automatically. The number of console programs that want to pull in X window or kde is my boggling. Those would not really be console programs, then, or their dependencies are directly or indirectly dependent on X or KDE. Knowing how to program myself when I see a make config menu on every single port it makes me want to cry. 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. You are mistaken about what the config options do. For example, I have hal installed, but don't want to use it when building xorg-server. The config options make that easy. 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? Letting the user explicitly configure what they want is better than just assuming based on what they have installed. If you really want to avoid the config options, set the BATCH variable in make.conf or on the command line. Or use config-recursive to get all of the config options over with at the beginning of the build. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
On Fri, 01 Apr 2011 16:58:04 -0700, Chris Telting christopher...@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, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: Port dependencies
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?). Over the years I've found that ghostscript and gd are two common culprits. Every time I see a webserver with X11 on it, it's because of these two. Of course, using ghostscript*-nox11 as well as setting WITHOUT_X11=yes solves a lot of this mess, but on a system that's already been infested, it's easier just to rebuild from scratch. I dearly love FreeBSD, but after a few hours of building world and upgrading ports/packages, walking over to my RHEL/CentOS machines and typing yum update -y reboot just brings tears to my eyes. -- Matt Emmerton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Port dependencies
On 04/01/2011 17:51, Polytropon wrote: On Fri, 01 Apr 2011 16:58:04 -0700, Chris Teltingchristopher...@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
Re: Port dependencies
Andrey Shuvikov wrote: Hello, I'm trying to figure out port dependencies on my (freshly installed) FreeBSD 7.0. For example, I have two automake ports: $ pkg_info | grep automake-1 automake-1.5_4,1GNU Standards-compliant Makefile generator (1.5) automake-1.6.3 GNU Standards-compliant Makefile generator (1.6) These particular ports are special, I don't think any port should list them as RUN_DEPENDS, but rather as BUILD_DEPENDS. So to answer your question, no, you don't need them. But if you were to recompile things, they would need to be built again. You should look at the automake-wrapper port. ade@ and des@ have done loads of work with the autotools. -- Philip M. Gollucci ([EMAIL PROTECTED]) o:703.549.2050x206 Senior System Admin - Riderway, Inc. http://riderway.com / http://ridecharge.com 1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
