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
Port dependencies
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. 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. The number of console programs that want to pull in X window or kde is my boggling. 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. 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? 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: fixing up port dependencies properly
John W wrote: I updated my ports tree with csup, and tried to run 'portmaster -na'. It gave me this: === The mail/p5-Email-Simple-Creator port has been deleted: Folded into p5-Email-Simple package Ok, that makes sense. But what do I do to fix it? It seems I need to replace dependencies on p5-Email-Simple-Creator with dependencies on p5-Email-Simple. But if I manually do that, won't my changes be blown away the next time I update ports? The committer who added the entry to /usr/ports/MOVED also seems to have adjusted any dependencies in the Ports tree, back on 24 Nov. 2009. So if you have an up-to-date ports tree, then after rebuilding the ports that used to depend upon p5-Email-Simple-Creator, those ports will depend instead upon p5-Email-Simple, and no further intervention will be needed. Perhaps I should use the '-o' (origin) option of portmaster? I'm not 100% sure what that does, incidentally (explanation welcome). I assume something like: portmaster -o p5-Email-Simple p5-Email-Simple-Creator I don't use portmaster often, but I think it should instead be: portmaster -o mail/p5-Email-Simple p5-Email-Simple-Creator Read the portmaster(1) manpage carefully, and look at the examples. Will those changes get blown away by the next update of ports? In this case, no. Is the most correct solution just to wait until all maintainers of ports which depend on p5-Email-Simple-Creator each update their makefiles to depend on p5-Email-Simple, instead? (Though that doesn't help in the short term :) That should already have been done. In other cases, if it has not, then you should send a message to the committer who made the change (if you aren't familiar with cvs(1), which is used to manage the ports repository, then you can use cvsweb.freebsd.org or www.freshports.org to find this information), and to the maintainers of the ports that have the outdated dependencies. If they don't respond within a reasonable amount of time, then file a Problem Report: http://www.freebsd.org/support/bugreports.html While they are fixing the problems, you can patch the dependent ports yourself (this is sometimes as simple as changing the *_DEPENDS line in the port Makefile; other times, it requires patches to the port sources), and then rebuild the ports; or you can try to use portmaster -o , or portupgrade -o, which will succeed in the simplest cases. You could also do it manually, by using sed(1) to substitute every occurrence of the old PKGNAME with the new PKGNAME in the @pkgdep lines in /var/db/pkg/*/+COMMENTS, and likewise for the PKGORIGIN values preceded by DEPORIGIN. However, be careful when tinkering with /var/db/pkg -- you should back it up first before making changes. 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: fixing up port dependencies properly
On 2/3/10, b. f. bf1...@googlemail.com wrote: John W wrote: -o , or portupgrade -o, which will succeed in the simplest cases. You could also do it manually, by using sed(1) to substitute every occurrence of the old PKGNAME with the new PKGNAME in the @pkgdep lines in /var/db/pkg/*/+COMMENTS, and likewise for the PKGORIGIN Sorry, that should be /var/db/pkg/*/+CONTENTS, of course. Where is my first cup of coffee.. 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: fixing up port dependencies
On Mon, 1 Feb 2010 21:35:58 -0800 John W jwde...@gmail.com articulated: Is the most correct solution just to wait until all maintainers of ports which depend on p5-Email-Simple-Creator each update their makefiles to depend on p5-Email-Simple, instead? (Though that doesn't help in the short term :) I'm curious of people's thoughts on this. This will correct it: portmanager -u -p -y DO update your ports tree before running the above command. -- Jerry ges...@yahoo.com |=== |=== |=== |=== | If *I* had a hammer, there'd be no more folk singers. ___ 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
fixing up port dependencies
Hello all, I'm going through a round of port upgrades and came upon a dependency issue. I could probably muscle through and make it work, but I'd like to know what people see as a correct solution to this problem. I'm still in the process of grokking the nitty-gritty bits of ports. Here's the issue: I updated my ports tree with csup, and tried to run 'portmaster -na'. It gave me this: === The mail/p5-Email-Simple-Creator port has been deleted: Folded into p5-Email-Simple package Ok, that makes sense. But what do I do to fix it? It seems I need to replace dependencies on p5-Email-Simple-Creator with dependencies on p5-Email-Simple. But if I manually do that, won't my changes be blown away the next time I update ports? Perhaps I should use the '-o' (origin) option of portmaster? I'm not 100% sure how that works, incidentally. I assume something like: portmaster -o p5-Email-Simple p5-Email-Simple-Creator Will those changes get blown away by the next update of ports? Is the most correct solution just to wait until all maintainers of ports which depend on p5-Email-Simple-Creator each update their makefiles to depend on p5-Email-Simple, instead? (Though that doesn't help in the short term :) I'm curious of people's thoughts on this. Thanks -John ___ 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
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]
Port dependencies
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) I didn't install them myself, so I tried to figure out how they were installed. But when I run $ pkg_info -R 'automake-1*' It doesn't show any dependencies (and I didn't delete any packages yet). Is there a way to figure out who (which port) installed them and do I need them both now? Thanks, Andrey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Toggling port dependencies
Hi: Some ports exists in multiple versions such as OpenLDAP, the most recent and recommended is 2.3, but some other ports depends on another version for example jabberd that requires 2.2. Some ports will let you choose which version to compile against but jabberd don't. How to I make a port compile against the installed version or a version of my choice? I know that it may fail, but I'd like to try. Thanks, Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: www.daemonsecurity.com/ca/8D03551FFCE04F06.crt Subject ID: 9E:AA:18:E6:94:7A:91:44:0A:E4:DD:87:73:7F:4E:82:E7:08:9C:72 Fingerprint: 5B:D5:1E:3E:47:E7:EC:1C:4C:C8:3A:19:CC:AE:14:F5:DF:18:0F:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Toggling port dependencies
On Tuesday 11 April 2006 11:39, Erik Norgaard wrote: Hi: Some ports exists in multiple versions such as OpenLDAP, the most recent and recommended is 2.3, but some other ports depends on another version for example jabberd that requires 2.2. Some ports will let you choose which version to compile against but jabberd don't. How to I make a port compile against the installed version or a version of my choice? I know that it may fail, but I'd like to try. You could try setting USE_OPENLDAP_VER=23 for the port. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Toggling port dependencies
On Tuesday 11 April 2006 13:25, RW wrote: You could try setting USE_OPENLDAP_VER=23 for the port. Actually, I see it conflict with 2.2, so it must be set globally. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Solved (I hope): Toggling port dependencies
RW wrote: On Tuesday 11 April 2006 13:25, RW wrote: You could try setting USE_OPENLDAP_VER=23 for the port. Actually, I see it conflict with 2.2, so it must be set globally. Yes, OpenLDAP 2.3 conflicts with 2.2, but jabberd by default assumes 2.2 so the build fails. Then rather than downgrading OpenLDAP since 2.3 is the recommended I'd prefer to force jabberd to build against 2.3. I've seen many ports doing this, for example squid. Some announces how to select a particular version. I don't know if your hint work with all ports. I tried your advice and things compiled and installed without any problems - now the question is if it works ... Thanks, Erik -- Ph: +34.666334818 web: www.locolomo.org S/MIME Certificate: www.daemonsecurity.com/ca/8D03551FFCE04F06.crt Subject ID: 9E:AA:18:E6:94:7A:91:44:0A:E4:DD:87:73:7F:4E:82:E7:08:9C:72 Fingerprint: 5B:D5:1E:3E:47:E7:EC:1C:4C:C8:3A:19:CC:AE:14:F5:DF:18:0F:B9 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Solved (I hope): Toggling port dependencies
On Tuesday 11 April 2006 16:10, Erik Norgaard wrote: RW wrote: On Tuesday 11 April 2006 13:25, RW wrote: You could try setting USE_OPENLDAP_VER=23 for the port. Actually, I see it conflict with 2.2, so it must be set globally. Yes, OpenLDAP 2.3 conflicts with 2.2, but jabberd by default assumes 2.2 so the build fails. Then rather than downgrading OpenLDAP since 2.3 is the recommended I'd prefer to force jabberd to build against 2.3. I've seen many ports doing this, for example squid. Some announces how to select a particular version. I don't know if your hint work with all ports. Actually I think I got this wrong; USE_OPENLDAP_VER will create spurious LDAP dependencies if set globally. It should have been WANT_OPENLDAP_VER=23 Dependencies on OpenLDAP are handled by the common ports makefiles. jabberd doesn't specify a version. I think it simply defaults to 2.2, even if 2.3 is installed. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Using pkg_add to satisfy port dependencies...
Hello all, Is there a way to tell the ports system to try to fetch port dependencies using the 'pkg_add' command rather than try to build the dependency first from source? Thanks! Luke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using pkg_add to satisfy port dependencies...
Luke Bakken wrote: Is there a way to tell the ports system to try to fetch port dependencies using the 'pkg_add' command rather than try to build the dependency first from source? pkg_add -r _port_ ought to fetch needed runtime dependencies, too? Or maybe you are looking for the portupgrade -P option: -P --use-packages Use packages instead of ports whenever available. portupgrade searches the local directories listed in PKG_PATH for each package to install or upgrade the current installation with, and if none is found, pkg_fetch(1) is invoked to fetch one from a remote site. If it doesn't work either, the port is used. -PP --use-packages-onlyNever use the port even if a package is not avail- able either locally or remotely, although you still have to keep your ports tree up-to-date so that portupgrade can check out what the latest version of each port is. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
mod_security install Apache 2, port dependencies problem
I installed Apache mod_security on my Apache 2 httpd. Since this my ports dependencies are off. It appears mod_security is only for Apache 1.3x according to make depends How do I solve the ports problem or where do I find mod_security for Apache 2. Thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2.1 port dependencies (PHP/PEAR)
On Sun, Aug 01, 2004 at 03:24:12PM -0500, Comrade Burnout wrote: when i try to use pkg_add ... i get the following: burnt# pkg_add -r pear-DB Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/Latest/pear-DB.tbz... Done. Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/All/php4-4.3.4_2.tbz... Done. pkg_add: package 'php4-4.3.4_2' conflicts with mod_php4-4.3.4_2,1 pkg_add: please use pkg_delete first to remove conflicting package(s) or -f to force installation pkg_add: pkg_add of dependency 'php4-4.3.4_2' failed! is there a way to tweak the Makefile locally to force the PEAR install to use the existing PHP version? What Makefile? You're installing via packages, and by the time the package has been built, there's no more need for Makefiles... In order to solve your problem, you can follow the instructions so helpfully printed out by pkg_add(1) and use the '-f' flag. That should work fine, as mod_php4 will fulfil the dependencies. Alternately, don't use packages to install PEAR modules. Ports are rather more flexible in this respect than packages, and for such things as PEAR where what's installed is pretty much program source code it makes little practical difference. The only problem with this approach is that you seem to be using a ports tree from around the time of 5.2.1-RELEASE, and since then both the ports tree and the available versions of the PEAR modules have had many months of further development. It's possible that new versions of some modules will have been released and the ones you want have been removed. But the answer to that is just a cvsup(1) away. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgpW4klgAMG8p.pgp Description: PGP signature
Re: FreeBSD 5.2.1 port dependencies (PHP/PEAR)
Comrade Burnout wrote: i recently upgraded some machines to FreeBSD 5.2.1-STABLE, and trying to install the PEAR objects (PHP stuff). I've looked through the INDEX file in my local ports collection, and the PEAR tree is looking for: php4-4.3.4 whereas mod_php4 and any of the other (non-PEAR ) PHP ports are looking for: mod_php4-4.3.4,1 PEAR needs a command line PHP binary to be able to run. The mod_php4 package only installs an Apache module and not the commandline PHP binary. Thus PEAR would be unuseable. The upside, is that the php4 package includes the command line binary, an Apache module and the CGI executable. Cheers Philip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2.1 port dependencies (PHP/PEAR)
Matthew Seaman wrote: On Sun, Aug 01, 2004 at 03:24:12PM -0500, Comrade Burnout wrote: when i try to use pkg_add ... i get the following: burnt# pkg_add -r pear-DB Fetching [1]ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/Latest/p ear-DB.tbz... Done. Fetching [2]ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/All/php4 -4.3.4_2.tbz... Done. pkg_add: package 'php4-4.3.4_2' conflicts with mod_php4-4.3.4_2,1 pkg_add: please use pkg_delete first to remove conflicting package(s) or -f to force installation pkg_add: pkg_add of dependency 'php4-4.3.4_2' failed! is there a way to tweak the Makefile locally to force the PEAR install to use the existing PHP version? What Makefile? You're installing via packages, and by the time the package has been built, there's no more need for Makefiles... OK, that's just my misunderstanding about ports vs anything else In order to solve your problem, you can follow the instructions so helpfully printed out by pkg_add(1) and use the '-f' flag. That should work fine, as mod_php4 will fulfil the dependencies. well, i thought so originally, but there was always some flavor of conflict. But the answer to that is just a cvsup(1) away. i've already installed cvsup, and supposedly pulled down the ports collection, but it doesn't seem that anything is local, even after running cvsup. i broke down and installed the PEAR stuff manually ... it did the job, but isn't necessarily the optimum solution. References 1. ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/Latest/pear-DB.tbz 2. ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/All/php4-4.3.4_2.tbz ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.2.1 port dependencies (PHP/PEAR)
Philip Murray wrote: Comrade Burnout wrote: i recently upgraded some machines to FreeBSD 5.2.1-STABLE, and trying to install the PEAR objects (PHP stuff). I've looked through the INDEX file in my local ports collection, and the PEAR tree is looking for: php4-4.3.4 whereas mod_php4 and any of the other (non-PEAR ) PHP ports are looking for: mod_php4-4.3.4,1 PEAR needs a command line PHP binary to be able to run. The mod_php4 package only installs an Apache module and not the commandline PHP binary. Thus PEAR would be unuseable. The upside, is that the php4 package includes the command line binary, an Apache module and the CGI executable. well, i did say and others. i had the php4 package installed, but there were other conflicts (that i don't remember at the moment -- the original problem was making sure the mysql-client libs were in synch with the mysql server i'm using. i tried to go up to mysql-4.1, but the packages for mod_php, php, etc. have a dependency listed for the 'earlier' release of mysql ) Cheers Philip ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.2.1 port dependencies (PHP/PEAR)
i recently upgraded some machines to FreeBSD 5.2.1-STABLE, and trying to install the PEAR objects (PHP stuff). I've looked through the INDEX file in my local ports collection, and the PEAR tree is looking for: php4-4.3.4 whereas mod_php4 and any of the other (non-PEAR ) PHP ports are looking for: mod_php4-4.3.4,1 when i try to use pkg_add ... i get the following: burnt# pkg_add -r pear-DB Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/Latest/pear-DB.tbz... Done. Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-5.2.1-release/All/php4-4.3.4_2.tbz... Done. pkg_add: package 'php4-4.3.4_2' conflicts with mod_php4-4.3.4_2,1 pkg_add: please use pkg_delete first to remove conflicting package(s) or -f to force installation pkg_add: pkg_add of dependency 'php4-4.3.4_2' failed! is there a way to tweak the Makefile locally to force the PEAR install to use the existing PHP version? everything on my new machine works with the existing PHP setup *but* one site that uses the PEAR classes. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Display installed port dependencies
platanthera platanthera at web.de writes: On Saturday 15 May 2004 03:44, Andy Smith wrote: Hi, Is there a simple way to display a list of all installed packages that depend on another given installed package? pkg_info -R foo will list all currently installed packages that depend on foo Doh! I'm really sorry, that is right in the man page which I DID read. I have no idea how I missed it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Display installed port dependencies
On Saturday 15 May 2004 03:44, Andy Smith wrote: Hi, Is there a simple way to display a list of all installed packages that depend on another given installed package? pkg_info -R foo will list all currently installed packages that depend on foo regards ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Display installed port dependencies
Hi, Is there a simple way to display a list of all installed packages that depend on another given installed package? i.e. say I would like to know every installed package that depends on gmake which I also have installed. Is there any quick way to display this? I am aware of portsearch which will allow me to get a nice list of every port that depends on another port, but as far as I can see this only operates on the ports collection, not just the ones installed as packages. Thanks, Andy -- http://freebsdwiki.org/ - Encrypted mail welcome - keyid 0xBF15490B Q. How many mathematicians does it take to change a light bulb? A. Only one - who gives it to six Californians, thereby reducing the problem to an earlier joke. pgpl5vPMAVjxi.pgp Description: PGP signature
prefetching port dependencies
Quick question: I'm getting interested in using portupgrade -FR to prefetch a port's source and its dependencies (and maybe even run the fetching in a 2nd session while other parts are compiling). But I can only get it to work on stuff that is already installed. It works great then. Is there an equivalent means to prefetch dependencies for a port that ISN'T installed yet? For example, I hadn't installed mozilla yet on this box but when I ran: portupgrade -FR mozilla-devel I got an error that there was no such package installed. Sorry if this is a newbie question. [I tried to research this but case-insensitivity (-fr is diff than -FR) in search engines was making it useless.] = Scott I. Remick --==-- ICQ: 450152 Save the internet - Use Mozilla: http://home.adelphia.net/~sremick/mozilla/ Voici mon secret. Il est tres simple: on ne voit bien qu'avec le coeur. L'essentiel est invisible pour les yeux. No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: prefetching port dependencies
On Mon, Nov 18, 2002 at 02:31:09PM -0800, Scott I. Remick wrote: Quick question: I'm getting interested in using portupgrade -FR to prefetch a port's source and its dependencies (and maybe even run the fetching in a 2nd session while other parts are compiling). But I can only get it to work on stuff that is already installed. It works great then. Is there an equivalent means to prefetch dependencies for a port that ISN'T installed yet? For example, I hadn't installed mozilla yet on this box but when I ran: portupgrade -FR mozilla-devel I got an error that there was no such package installed. Sorry if this is a newbie question. [I tried to research this but case-insensitivity (-fr is diff than -FR) in search engines was making it useless.] Go to the desired port and do a 'make fetch-recursive'. This will fetch all the distfiles of the port and all its dependencies. (Doing a 'make checksum-recursive' is an even better idea since that will check all the checksums of the distfiles too.) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: prefetching port dependencies
On Monday 18 November 2002 05:31 pm, Scott I. Remick wrote: Quick question: I'm getting interested in using portupgrade -FR to prefetch a port's source and its dependencies (and maybe even run the fetching in a 2nd session while other parts are compiling). But I can only get it to work on stuff that is already installed. It works great then. Is there an equivalent means to prefetch dependencies for a port that ISN'T installed yet? For example, I hadn't installed mozilla yet on this box but when I ran: portupgrade -FR mozilla-devel Try portupgrade -FRN /usr/ports/www/mozilla-devel (from the manpage) I got an error that there was no such package installed. Sorry if this is a newbie question. [I tried to research this but case-insensitivity (-fr is diff than -FR) in search engines was making it useless.] = Scott I. Remick --==-- ICQ: 450152 Save the internet - Use Mozilla: http://home.adelphia.net/~sremick/mozilla/ Voici mon secret. Il est tres simple: on ne voit bien qu'avec le coeur. L'essentiel est invisible pour les yeux. No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: prefetching port dependencies
On 2002-11-18 23:42, Erik Trulsson [EMAIL PROTECTED] wrote: On Mon, Nov 18, 2002 at 02:31:09PM -0800, Scott I. Remick wrote: I'm getting interested in using portupgrade -FR to prefetch a port's source and its dependencies (and maybe even run the fetching in a 2nd session while other parts are compiling). But I can only get it to work on stuff that is already installed. It works great then. Is there an equivalent means to prefetch dependencies for a port that ISN'T installed yet? For example, I hadn't installed mozilla yet on this box but when I ran: Go to the desired port and do a 'make fetch-recursive'. This will fetch all the distfiles of the port and all its dependencies. (Doing a 'make checksum-recursive' is an even better idea since that will check all the checksums of the distfiles too.) Yep, that works great :) I'd only like to add a handy tip to avoid surprises later when building the ports. If you plan to build the ports with options different from the port defaults (such as WITHOUT_X11=yes or WITH_SSL=yes), it is a good idea to pass the exact same options to make fetch-recursive too. Some times, depending on what options are selected a port automagically downloads different patches or distfiles. By passing the same options in both make fetch... and later make install command lines, you will be sure that the port won't decide to fetch some extra stuff when you start building it while offline. Giorgos. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
