macports and OS-X upgrades
in [Mac Systems]
|
From: Jolly Roger on 4 May 2010 16:12 In article <slrnhu0ili.1iv.ianji33(a)zenatode.org.uk>, Ian Gregory <ianji33(a)googlemail.com> wrote: > On 2010-05-04, Jolly Roger <jollyroger(a)pobox.com> wrote: > > In article <4bdfe2f7$0$18923$c3e8da3(a)news.astraweb.com>, > > JF Mezei <jfmezei.spamnot(a)vaxination.ca> wrote: > >> > >> (I know I had used it to install stuff like imagemagick for instance). > >> > >> Right now, it is busy installing all of the world's software, including > >> openssl, python and a gazillion other stuff that come pre-installed on > >> the mac. > > > > That's just silly. What a waste of space and time. This is one of the > > many reasons I avoid package managers like macports and instead compile > > what I need, and only what I need, myself. > > I install only what I need using MacPorts and it is simpler than > downloading/configuring/building/installing from source. Yes it does > install its own version of dependencies which may come pre-installed on > the Mac but there are very good reasons for that. > > Sure if you only want a single program and it has no dependencies or can > be linked to the Mac's pre-installed libraries there is an argument for > not using MacPorts (and clearly if what you want is not available > through MacPorts you have no choice). If you want more than half a dozen > programs or programs with a lot of dependencies that don't come > pre-installed then MacPorts saves a lot of time. > > In particular, I can just type "sudo port upgrade installed" to upgrade > everything to the latest build (which I tend to do every time I run > Software Update). I have installed a fair few packages using MacPorts > and automatically installed dependencies bring the total to about 50 > packages in /opt/local, consuming about 340 MB - less than 0.1% of my > disk. > > I am not afraid of building stuff myself (I spent years doing it on > Solaris) but why do it the hard way when MacPorts automates the whole > thing and greatly simplifies management? Because all that "simplification" comes at a high cost. By and large, most open source software I need has few dependencies and is very simple to compile and install (the typical ./configure, make, make install is all that is needed in most cases). As already mentioned, all those dependencies cause duplication with built-in software, wasting lots of space and potentially introducing mismatches between the duplicate copies. Also, dependency management can and does backfire when dependency conflicts arise, which creates a huge, complex problem for those affected by it. -- Send responses to the relevant news group rather than email to me. E-mail sent to this address may be devoured by my very hungry SPAM filter. Due to Google's refusal to prevent spammers from posting messages through their servers, I often ignore posts from Google Groups. Use a real news client if you want me to see your posts. JR
From: Ian Gregory on 4 May 2010 17:33 On 2010-05-04, Jolly Roger <jollyroger(a)pobox.com> wrote: > In article <slrnhu0ili.1iv.ianji33(a)zenatode.org.uk>, > Ian Gregory <ianji33(a)googlemail.com> wrote: >> >> I am not afraid of building stuff myself (I spent years doing it on >> Solaris) but why do it the hard way when MacPorts automates the whole >> thing and greatly simplifies management? > > Because all that "simplification" comes at a high cost. By and large, > most open source software I need has few dependencies and is very simple > to compile and install (the typical ./configure, make, make install is > all that is needed in most cases). As already mentioned, all those > dependencies cause duplication with built-in software, wasting lots of > space and potentially introducing mismatches between the duplicate > copies. I don't consider less than 0.1% of my disk to be lots of wasted space, and it is precisely to avoid "mismatches" that MacPorts installs its own copy of stuff in /opt/local even if it is included with Mac OS X (often the MacPorts version is newer). Everything installed by MacPorts is self-contained within /opt/local so it can't get randomly hosed when Software Update installs a new library. By the way, if the stuff you use has few dependencies then MacPorts would cause little duplication. > Also, dependency management can and does backfire when dependency > conflicts arise, which creates a huge, complex problem for those > affected by it. Which is why it is so useful to have something that manages it for us. In my experience the simplification has no downside. The MacPorts people have done all the work. They resolve any problems with new releases and get it all sorted so if you need X you can type "sudo port install X" and everything just works. I am not trying to persuade you to use MacPorts - feel free to continue doing it your way. I just don't like to think of other Mac users being put off using MacPorts by your unfounded (IMHO) criticism. Ian -- Ian Gregory http://www.zenatode.org.uk/
From: Jolly Roger on 4 May 2010 17:43 In article <slrnhu14lv.200.ianji33(a)zenatode.org.uk>, Ian Gregory <ianji33(a)googlemail.com> wrote: > On 2010-05-04, Jolly Roger <jollyroger(a)pobox.com> wrote: > > In article <slrnhu0ili.1iv.ianji33(a)zenatode.org.uk>, > > Ian Gregory <ianji33(a)googlemail.com> wrote: > >> > >> I am not afraid of building stuff myself (I spent years doing it on > >> Solaris) but why do it the hard way when MacPorts automates the whole > >> thing and greatly simplifies management? > > > > Because all that "simplification" comes at a high cost. By and large, > > most open source software I need has few dependencies and is very simple > > to compile and install (the typical ./configure, make, make install is > > all that is needed in most cases). As already mentioned, all those > > dependencies cause duplication with built-in software, wasting lots of > > space and potentially introducing mismatches between the duplicate > > copies. > > I don't consider less than 0.1% of my disk to be lots of wasted space, > and it is precisely to avoid "mismatches" that MacPorts installs its own > copy of stuff in /opt/local even if it is included with Mac OS X (often > the MacPorts version is newer). Everything installed by MacPorts is > self-contained within /opt/local so it can't get randomly hosed when > Software Update installs a new library. By the way, if the stuff you use > has few dependencies then MacPorts would cause little duplication. I prefer to have my open source stuff in /usr/local, where it belongs. Thanks, but no thanks. > > Also, dependency management can and does backfire when dependency > > conflicts arise, which creates a huge, complex problem for those > > affected by it. > > Which is why it is so useful to have something that manages it for us. > In my experience the simplification has no downside. The MacPorts people > have done all the work. They resolve any problems with new releases and > get it all sorted so if you need X you can type "sudo port install X" > and everything just works. > > I am not trying to persuade you to use MacPorts - feel free to continue > doing it your way. I just don't like to think of other Mac users being > put off using MacPorts by your unfounded (IMHO) criticism. I don't have direct experience with MacPorts in particular, but i can tell you with great certainty that package managers I've used on Linux have such complex dependencies to manage that they do backfire and cause huge problems for you if you're not very careful. To each, his own, of course. Me? I'm happy to compile my own. -- Send responses to the relevant news group rather than email to me. E-mail sent to this address may be devoured by my very hungry SPAM filter. Due to Google's refusal to prevent spammers from posting messages through their servers, I often ignore posts from Google Groups. Use a real news client if you want me to see your posts. JR
From: Jolly Roger on 4 May 2010 17:45 In article <slrnhu12dh.2jll.g.kreme(a)ibook-g4.local>, Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote: > In message <jollyroger-959F8A.15121504052010(a)news.individual.net> > Jolly Roger <jollyroger(a)pobox.com> wrote: > > Because all that "simplification" comes at a high cost. By and large, > > most open source software I need has few dependencies and is very simple > > to compile and install (the typical ./configure, make, make install is > > all that is needed in most cases). As already mentioned, all those > > dependencies cause duplication with built-in software, wasting lots of > > space > > HD space is cheap. The entire install of ports on my development machine is > barely 600MB. > > > and potentially introducing mismatches between the duplicate > > copies. > > No, this is why ports installs its own libraries. No, you misunderstood. If something I install with MacPorts needs OpenSSH, and I have the built-in OpenSSH configured a certain way, I now have two versions of OpenSSH installed, with different configurations. No thanks. -- Send responses to the relevant news group rather than email to me. E-mail sent to this address may be devoured by my very hungry SPAM filter. Due to Google's refusal to prevent spammers from posting messages through their servers, I often ignore posts from Google Groups. Use a real news client if you want me to see your posts. JR
From: Warren Oates on 4 May 2010 18:10
In article <jollyroger-7192AC.16450204052010(a)news.individual.net>, Jolly Roger <jollyroger(a)pobox.com> wrote: > No, you misunderstood. If something I install with MacPorts needs > OpenSSH, and I have the built-in OpenSSH configured a certain way, I now > have two versions of OpenSSH installed, with different configurations. > No thanks. Well, unfortunately, Apple don't update the basic stuff very often or very well, so even without all the macports fluff, I still have my own duplicate copies (usually in /usr/local, but I keep some stuff in ~/ as well, and since you never can tell what arcane use the system might want to make of the Apple-installed stuff, so you can't just delete it). When Apple _do_ update something, they over-write _their_ old copy, so you really don't want to be making changes that you might later rely on in court. -- Very old woody beets will never cook tender. -- Fannie Farmer |