homebrew and macports together?
Hi I am using homebrew at the moment, but there are certain packges, which are not on homebrew (e.g. awesome and kde apps). Therefore I am thinking abiout using these two package managers in parallel. I know this *can* cause problems, but is it likely to cause problems? What do I have to be aware about? Any experiences? Thanks, Rainer -- Rainer M. Krug email: RMKrugatgmaildotcom ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Install from HEAD instead current stable version?
Hi I am looking for an easy way of installing the development version (HEAD) of grass. under homebrew, I can simply say , | brew install grass --HEAD ` to instal the development version instead of the stable one - is there something similar in port? Thanks, Rainer -- Rainer M. Krug email: RMKrugatgmaildotcom ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: homebrew and macports together?
On Thu, Jul 4, 2013 at 9:44 AM, Rainer M Krug wrote: Hi I am using homebrew at the moment, but there are certain packges, which are not on homebrew (e.g. awesome and kde apps). Therefore I am thinking abiout using these two package managers in parallel. I know this *can* cause problems, but is it likely to cause problems? What do I have to be aware about? Any experiences? If you need those packages only occasionally, you could create a shortcut to switch the PATH settings. Often the most problems can be prevented by including just MacPorts or just Homebrew into PATH and leaving the other one out. The most problematic part is probably if you have Homebrew in PATH before MacPorts and you try to install a MacPorts package from source (or vice versa). Apart from that my personal opinion is just try. Some software is written in such a way that it explicitly looks for libraries in /sw or /opt/local to be more user-friendly and account for the fact that users might have dependencies in Fink, Macports, ... It could happen that a package that you try to install with Homebrew would accidentally pick up its dependency from MacPorts. All these are bugs that can/should be reported and fixed, it's just that you never know in advance and developers rarely test such configurations. Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: homebrew and macports together?
Mojca Miklavec mojca.miklavec.li...@gmail.com writes: On Thu, Jul 4, 2013 at 9:44 AM, Rainer M Krug wrote: Hi I am using homebrew at the moment, but there are certain packges, which are not on homebrew (e.g. awesome and kde apps). Therefore I am thinking abiout using these two package managers in parallel. I know this *can* cause problems, but is it likely to cause problems? What do I have to be aware about? Any experiences? If you need those packages only occasionally, you could create a shortcut to switch the PATH settings. Often the most problems can be prevented by including just MacPorts or just Homebrew into PATH and leaving the other one out. I thought along the same lines - but I am thinking of trying to use awesome windows manager (macports only) and at the same time I am using offlineimap and notmuch which are installed via homebrew - so this wont work in this case. The most problematic part is probably if you have Homebrew in PATH before MacPorts and you try to install a MacPorts package from source (or vice versa). Apart from that my personal opinion is just try. Some software is written in such a way that it explicitly looks for libraries in /sw or /opt/local to be more user-friendly and account for the fact that users might have dependencies in Fink, Macports, ... It could happen that a package that you try to install with Homebrew would accidentally pick up its dependency from MacPorts. All these are bugs that can/should be reported and fixed, it's just that you never know in advance and developers rarely test such configurations. Thanks - I will see what I do - I might switch completely to macports? I will see. Rainer Mojca -- Rainer M. Krug email: RMKrugatgmaildotcom ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Install from HEAD instead current stable version?
Hi, On Thu, Jul 04, 2013 at 10:08:01AM +0200, Rainer M Krug wrote: I am looking for an easy way of installing the development version (HEAD) of grass. under homebrew, I can simply say , | brew install grass --HEAD ` to instal the development version instead of the stable one - is there something similar in port? MacPorts deliberately does not support this; there are no metrics to find out when to consider such a port outdated and the build does not yield reproducible results. If you need this, create a local portfile repository, copy the grass Portfile to this tree, modify it to fetch from current git head and change the commitish whenever you need a new version. You'll probably have to add a artificial version number (like a date) to get port to recognize that grass has been updated, since git commits aren't monotonic. BTW: MacPorts will not stop you from specifying HEAD or master as git commit to fetch. You can use sudo port upgrade --force grass to build a new version then. -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: homebrew and macports together?
Hi, On Thu, Jul 04, 2013 at 09:44:06AM +0200, Rainer M Krug wrote: Therefore I am thinking abiout using these two package managers in parallel. I know this *can* cause problems, but is it likely to cause problems? What do I have to be aware about? Any experiences? Unfortunately it is rather likely to produce hard-to-debug problems. However, I am working on a mechanism built into port to prevent problems with homebrew or fink co-installed on the same machine called trace mode. It works by hiding files in /usr/local and /sw (amongst others) from the build process. Unfortunately it was broken for quite a while now and I've only recently gotten to fix it. If you want to give it a shot, you should probably use trunk for now (although I'm planning to get it into the upcoming 2.2 release). -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Install from HEAD instead current stable version?
Clemens Lang c...@macports.org writes: Hi, On Thu, Jul 04, 2013 at 10:08:01AM +0200, Rainer M Krug wrote: I am looking for an easy way of installing the development version (HEAD) of grass. under homebrew, I can simply say , | brew install grass --HEAD ` to instal the development version instead of the stable one - is there something similar in port? MacPorts deliberately does not support this; there are no metrics to find out when to consider such a port outdated and the build does not yield reproducible results. If you need this, create a local portfile repository, copy the grass Portfile to this tree, modify it to fetch from current git head and change the commitish whenever you need a new version. You'll probably have to add a artificial version number (like a date) to get port to recognize that grass has been updated, since git commits aren't monotonic. OK - thanks for the info. BTW: MacPorts will not stop you from specifying HEAD or master as git commit to fetch. You can use sudo port upgrade --force grass to build a new version then. So then I would have to install grass as usual via , | port install grass ` and then upgrade it and specify to use HEAD to fetch - how can I do this? Rainer -- Rainer M. Krug email: RMKrugatgmaildotcom ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: homebrew and macports together?
Clemens Lang c...@macports.org writes: Hi, On Thu, Jul 04, 2013 at 09:44:06AM +0200, Rainer M Krug wrote: Therefore I am thinking abiout using these two package managers in parallel. I know this *can* cause problems, but is it likely to cause problems? What do I have to be aware about? Any experiences? Unfortunately it is rather likely to produce hard-to-debug problems. However, I am working on a mechanism built into port to prevent problems with homebrew or fink co-installed on the same machine called trace mode. It works by hiding files in /usr/local and /sw (amongst others) from the build process. Unfortunately it was broken for quite a while now and I've only recently gotten to fix it. If you want to give it a shot, you should probably use trunk for now (although I'm planning to get it into the upcoming 2.2 release). #secure method=pgpmime mode=sign Sounds great - I will probably wait then for the 2.2 release. This would then mean, that two package managers can co-exist, or only that macports can work reliably with homebrew installed, but not the other way round? Rainer -- Rainer M. Krug email: RMKrugatgmaildotcom ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Install from HEAD instead current stable version?
On Thu, Jul 04, 2013 at 11:10:33AM +0200, Rainer M Krug wrote: So then I would have to install grass as usual via , | port install grass ` Yes. and then upgrade it and specify to use HEAD to fetch - how can I do this? MacPorts has no way to do this from the command line like homebrew does. You need to have a Portfile that explicitly specifies what to download (where you can put in git HEAD, if you want). Since such a Portfile will not be accepted into the main port tree, you need to have a local portfile repository (as described in [1]), where you can put this modified Portfile for MacPorts to pick up. The guide also has all the information on how to fetch from git [2]. [1] https://guide.macports.org/#development.local-repositories [2] https://guide.macports.org/#reference.phases.fetch.git HTH, -- Clemens Lang ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: homebrew and macports together?
On Thu, Jul 4, 2013 at 10:27 AM, Rainer M Krug wrote: Mojca Miklavec writes: I thought along the same lines - but I am thinking of trying to use awesome windows manager (macports only) and at the same time I am using offlineimap and notmuch which are installed via homebrew - so this wont work in this case. I don't know how these programs work, but apart from the need for removing Homebrew/MacPorts from PATH during installation (also in the spirit of what Clemens Lang wrote), I believe that having both in PATH while using the programs should mostly work. In many cases it's not even necessary that you have MacPorts in PATH at all to be able to run its programs. Details really depend on individual programs (and I don't know any of those you mention). from the other post This would then mean, that two package managers can co-exist, or only that macports can work reliably with homebrew installed, but not the other way round? It means that MacPorts installation should not have problems if Homebrew is in PATH. Homebrew can still have problems with interfering programs from MacPorts unless Homebrew does the same. It also makes a huge difference when you decide which one comes first in PATH I would suggest you to simply try (and don't complain too much in case of problems ;). Mojca ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: homebrew and macports together?
Mojca Miklavec mojca.miklavec.li...@gmail.com writes: On Thu, Jul 4, 2013 at 10:27 AM, Rainer M Krug wrote: Mojca Miklavec writes: I thought along the same lines - but I am thinking of trying to use awesome windows manager (macports only) and at the same time I am using offlineimap and notmuch which are installed via homebrew - so this wont work in this case. I don't know how these programs work, but apart from the need for removing Homebrew/MacPorts from PATH during installation (also in the spirit of what Clemens Lang wrote), I believe that having both in PATH while using the programs should mostly work. In many cases it's not even necessary that you have MacPorts in PATH at all to be able to run its programs. Details really depend on individual programs (and I don't know any of those you mention). Thanks - that clarifies. from the other post This would then mean, that two package managers can co-exist, or only that macports can work reliably with homebrew installed, but not the other way round? It means that MacPorts installation should not have problems if Homebrew is in PATH. Homebrew can still have problems with interfering programs from MacPorts unless Homebrew does the same. It also makes a huge difference when you decide which one comes first in PATH Ok. I would suggest you to simply try (and don't complain too much in case of problems ;). No worries - I guess using two package managers is like entering a mine field which is surrounded by huge red signs saying: DO NOT ENTER ENTERING AT OWN RISK Cheers, Rainer Mojca #secure method=pgpmime mode=sign -- Rainer M. Krug email: RMKrugatgmaildotcom ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Install from HEAD instead current stable version?
Clemens Lang c...@macports.org writes: On Thu, Jul 04, 2013 at 11:10:33AM +0200, Rainer M Krug wrote: So then I would have to install grass as usual via , | port install grass ` Yes. and then upgrade it and specify to use HEAD to fetch - how can I do this? MacPorts has no way to do this from the command line like homebrew does. You need to have a Portfile that explicitly specifies what to download (where you can put in git HEAD, if you want). Since such a Portfile will not be accepted into the main port tree, you need to have a local portfile repository (as described in [1]), where you can put this modified Portfile for MacPorts to pick up. The guide also has all the information on how to fetch from git [2]. [1] https://guide.macports.org/#development.local-repositories [2] https://guide.macports.org/#reference.phases.fetch.git OK - understood. Thanks a lot, Rainer HTH, -- Rainer M. Krug email: RMKrugatgmaildotcom ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Macports does what I want (?) not what I say
Well, the answer lies in this command: $ portrdeps percona-toolkit The following ports are dependencies of percona-toolkit @2.1.5_0+perl5_16: p5.16-time-hires perl5.16 gdbm gettext expat libiconv gperf ncurses p5.16-dbd-mysql p5.16-dbi p5.16-test-simple p5.16-sql-statement p5.16-clone p5.16-params-util mysql5 zlib xz openssl tcp_wrappers readline p5.16-term-readkey So all MacPorts does is upgrading all dependencies recursively. This is by default, I believe. The answer as to why are your command line options ignored by MacPorts is quite simple. I suppose (and here I'm gonna guess) you didn't really do a port upgrade percona-toolkit but rather a sudo port upgrade percona-toolkit. The thing is, sudo ignores all your aliases! but since you shadowed a command (port) with an alias (alias port=port -cn) sudo didn't complain and happily executed the port command (with no options!). So, I either suggest running sudo port -cn upgrade percona-toolkit, or defining an alias like alias sp=sudo port -cn and using that. I hope this helps, Aljaž On 04/lug/2013, at 14:32, Enrico Placci e.pla...@gmail.com wrote: Hello everybody, I hope my email does not sound too whiney, my intention is to give constructive feedback, hopefully my frustration won't overshadow that. I'm writing you from a burning laptop, where macports decided to be too smart and did what it thought I wanted. A few years ago I absolutely loved how macports did exactly what I told it to do: # port install myport myport is already installed # port upgrade myport upgrading myport I absolutely loved it! Sometimes you just need something quickly and you don't care what version it is. Maybe you just forgot you previously installed it. Also it didn't upgrade all dependencies unless you asked it to. Again, sometimes you want to get some tool compiled quickly and you don't care if a new minor version of gtk is out, the previous one will work just fine. So what I started doing is I don't update port definitions for months so that I don't have to upgrade half my libraries every time I install a tool, which is quite annoying as I'd like to compile a recent version of the new thing I'm installing, and I'd like to upgrade only the dependencies that need upgrading. So today I wanted to upgrade percona-toolkit. I did a port selfupdate and a port upgrade percona-toolkit . These are the requirements of percona-toolkit: --- Most tools require: * Perl v5.8 or newer * Bash v3 or newer * Core Perl modules like Time::HiRes Tools that connect to MySQL require: * Perl modules DBI and DBD::mysql * MySQL 5.0 or newer -- Aljaž Srebrnič a.k.a g5pw My public key: http://bit.ly/g5pw_pubkey ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: homebrew and macports together?
On Jul 4, 2013, at 02:44, Rainer M Krug wrote: I am using homebrew at the moment, but there are certain packges, which are not on homebrew (e.g. awesome and kde apps). Therefore I am thinking abiout using these two package managers in parallel. I know this *can* cause problems, but is it likely to cause problems? What do I have to be aware about? Any experiences? Unlike some of the other responders in this thread, I will advise you not to try this. We do not support this configuration, for some of the reasons already stated, and if we discover you are using this configuration when you ask for help, we will decline to help you until you uninstall your non-MacPorts package managers. On Jul 4, 2013, at 03:27, Rainer M Krug wrote: I thought along the same lines - but I am thinking of trying to use awesome windows manager (macports only) and at the same time I am using offlineimap and notmuch which are installed via homebrew - so this wont work in this case. offlineimap and notmuch are of course available in MacPorts as well. Thanks - I will see what I do - I might switch completely to macports? I will see. I would recommend you give that a try. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Macports does what I want (?) not what I say
On Jul 4, 2013, at 07:32, Enrico Placci wrote: I hope my email does not sound too whiney, my intention is to give constructive feedback, hopefully my frustration won't overshadow that. I'm writing you from a burning laptop, where macports decided to be too smart and did what it thought I wanted. A few years ago I absolutely loved how macports did exactly what I told it to do: # port install myport myport is already installed # port upgrade myport upgrading myport I absolutely loved it! Sometimes you just need something quickly and you don't care what version it is. Maybe you just forgot you previously installed it. Also it didn't upgrade all dependencies unless you asked it to. Again, sometimes you want to get some tool compiled quickly and you don't care if a new minor version of gtk is out, the previous one will work just fine. So what I started doing is I don't update port definitions for months so that I don't have to upgrade half my libraries every time I install a tool, which is quite annoying as I'd like to compile a recent version of the new thing I'm installing, and I'd like to upgrade only the dependencies that need upgrading. So today I wanted to upgrade percona-toolkit. I did a port selfupdate and a port upgrade percona-toolkit . These are the requirements of percona-toolkit: --- Most tools require: * Perl v5.8 or newer * Bash v3 or newer * Core Perl modules like Time::HiRes Tools that connect to MySQL require: * Perl modules DBI and DBD::mysql * MySQL 5.0 or newer --- So why would I want to upgrade ncurses @5.9_1 to @5.9_2 gettext @0.18.2_1 to @0.18.2.1_0 perl @5.12.4_1+dtrace to @5.12.4_2+dtrace zlib @1.2.7_0 to @1.2.8_0 openssl @1.0.1c_0 to @1.0.1e_1 mysql5 @5.1.66_1 to @5.1.70_0 ? Because they are direct or indirect dependencies of the port you asked to install or upgrade. Is there any way I can restore the previous behaviour both in regards to upgrading dependencies and upgrading when I say install? MacPorts has always first upgraded dependencies of the ports you asked to install or upgrade. Not doing so would be completely counterproductive to the way that MacPorts is designed to work. We will not help you attempt to circumvent a fundamental functionality of MacPorts, because it would likely increase our support burden when you do this and then ask us why things aren't working right. I'd really love to have back a tool that does what I say not what it believes I want. I already put this into my aliases port='port -cn' but it obviously doesn't work. -c is autoclean mode which is the default; you do not need to specify it. -n is don't-upgrade-dependencies mode; please don't attempt to use that on a regular basis; it's meant for special situations only. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Macports does what I want (?) not what I say
On 2013-07-04, at 13:44, Aljaž Srebrnič wrote: So, I either suggest running sudo port -cn upgrade percona-toolkit, or defining an alias like alias sp=sudo port -cn and using that. I hope this helps, Aljaž Thank you , it helps! I totally missed that. On 2013-07-04, at 13:57, Ryan Schmidt wrote: On Jul 4, 2013, at 07:32, Enrico Placci wrote: So why would I want to upgrade ncurses @5.9_1 to @5.9_2 gettext @0.18.2_1 to @0.18.2.1_0 perl @5.12.4_1+dtrace to @5.12.4_2+dtrace zlib @1.2.7_0 to @1.2.8_0 openssl @1.0.1c_0 to @1.0.1e_1 mysql5 @5.1.66_1 to @5.1.70_0 ? Because they are direct or indirect dependencies of the port you asked to install or upgrade. But there is really no need to upgrade them, they already satisfy the dependency. This wasn't even too bad, after all, when I hit gtk I want to cry. Is there any way I can restore the previous behaviour both in regards to upgrading dependencies and upgrading when I say install? MacPorts has always first upgraded dependencies of the ports you asked to install or upgrade. Not doing so would be completely counterproductive to the way that MacPorts is designed to work. We will not help you attempt to circumvent a fundamental functionality of MacPorts, because it would likely increase our support burden when you do this and then ask us why things aren't working right. Maybe I mistook a very old bug (in the ports if not in macports, I'm sure it happened) for a feature, but I really liked it. I assume from your answer that there is no intention whatsoever of implementing a = check for dependencies versions. It doesn't sound so unreasonable to me, but then again I'm not the one developing it... I'd really love to have back a tool that does what I say not what it believes I want. I already put this into my aliases port='port -cn' but it obviously doesn't work. -c is autoclean mode which is the default; you do not need to specify it. -n is don't-upgrade-dependencies mode; please don't attempt to use that on a regular basis; it's meant for special situations only. I promise I will not come back crying before removing the option and re-updating everything, but I just can't stand hours of compilation on my tiny cpu while I'm working. I'll try to schedule over-weekend updates for the dependencies... Thanks for the feedback Enrico ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Macports does what I want (?) not what I say
Because they are direct or indirect dependencies of the port you asked to install or upgrade. But there is really no need to upgrade them, they already satisfy the dependency. This wasn't even too bad, after all, when I hit gtk I want to cry. oh but there is a need to upgrade all dependencies. Often changes are introduced into ports that require updates in dependant ports, so both have to be committed at the same time. If you then where able to update one, without the other you would get a broken system which is why this is not something that is at all recommended. Why do you care so much about how many updates come in ? Have you disabled binary packages, kin which case you will not have to build most yourself (a few still have to be for various reasons). With binary packages, updates are quick and painless, so why care. Chris Is there any way I can restore the previous behaviour both in regards to upgrading dependencies and upgrading when I say install? MacPorts has always first upgraded dependencies of the ports you asked to install or upgrade. Not doing so would be completely counterproductive to the way that MacPorts is designed to work. We will not help you attempt to circumvent a fundamental functionality of MacPorts, because it would likely increase our support burden when you do this and then ask us why things aren't working right. Maybe I mistook a very old bug (in the ports if not in macports, I'm sure it happened) for a feature, but I really liked it. I assume from your answer that there is no intention whatsoever of implementing a = check for dependencies versions. It doesn't sound so unreasonable to me, but then again I'm not the one developing it... I'd really love to have back a tool that does what I say not what it believes I want. I already put this into my aliases port='port -cn' but it obviously doesn't work. -c is autoclean mode which is the default; you do not need to specify it. -n is don't-upgrade-dependencies mode; please don't attempt to use that on a regular basis; it's meant for special situations only. I promise I will not come back crying before removing the option and re-updating everything, but I just can't stand hours of compilation on my tiny cpu while I'm working. I'll try to schedule over-weekend updates for the dependencies... Thanks for the feedback Enrico ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Macports does what I want (?) not what I say
On Jul 4, 2013, at 08:39, Enrico Placci wrote: On 2013-07-04, at 13:57, Ryan Schmidt wrote: On Jul 4, 2013, at 07:32, Enrico Placci wrote: So why would I want to upgrade ncurses @5.9_1 to @5.9_2 gettext @0.18.2_1 to @0.18.2.1_0 perl @5.12.4_1+dtrace to @5.12.4_2+dtrace zlib @1.2.7_0 to @1.2.8_0 openssl @1.0.1c_0 to @1.0.1e_1 mysql5 @5.1.66_1 to @5.1.70_0 ? Because they are direct or indirect dependencies of the port you asked to install or upgrade. But there is really no need to upgrade them, they already satisfy the dependency. This wasn't even too bad, after all, when I hit gtk I want to cry. Sometimes when port versions are updated, that causes bugs to be fixed. We don't want you to experience those bugs, nor do we want to spend time dealing with bug reports from users for bugs that are already fixed. Sometimes ports change in ways other than just the version of the upstream software, and you don't have any visibility to such changes just by looking at the output of port outdated. You know, for example, that ncurses was updated, but you don't know why. Part of the point of MacPorts is for you to be able to install software without having to know all about the intricacies of the dependencies or issues they might contain. To a certain extent, you have to trust us that when we make an update available to you, you should install it. The order of installation of such updates is significant. You should not circumvent the upgrading of dependencies (using -n) because that may in some cases defeat the purpose for the update. Is there any way I can restore the previous behaviour both in regards to upgrading dependencies and upgrading when I say install? MacPorts has always first upgraded dependencies of the ports you asked to install or upgrade. Not doing so would be completely counterproductive to the way that MacPorts is designed to work. We will not help you attempt to circumvent a fundamental functionality of MacPorts, because it would likely increase our support burden when you do this and then ask us why things aren't working right. Maybe I mistook a very old bug (in the ports if not in macports, I'm sure it happened) for a feature, but I really liked it. I assume from your answer that there is no intention whatsoever of implementing a = check for dependencies versions. It doesn't sound so unreasonable to me, but then again I'm not the one developing it… MacPorts does not have the capability to declare a dependency on a specific version of a dependency, nor does MacPorts have the capability to install an arbitrary version of a dependency. It's always only the version currently available in MacPorts. I'd really love to have back a tool that does what I say not what it believes I want. I already put this into my aliases port='port -cn' but it obviously doesn't work. -c is autoclean mode which is the default; you do not need to specify it. -n is don't-upgrade-dependencies mode; please don't attempt to use that on a regular basis; it's meant for special situations only. I promise I will not come back crying before removing the option and re-updating everything, but I just can't stand hours of compilation on my tiny cpu while I'm working. I'll try to schedule over-weekend updates for the dependencies… MacPorts has pre-built binaries now. This does not cover all ports, all systems, or all variants, but it does cover many. If you are on Snow Leopard, Lion, or Mountain Lion; on x86_64; using default prefix, applications_dir and frameworks_dir; and using default variants; then MacPorts should be downloading and using pre-built binaries instead of building from source. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Macports does what I want (?) not what I say
On Jul 4, 2013, at 09:01, Rainer Müller wrote: I want to share an unobvious feature of bash with you that helps in situations like this. Quoting the man page: If the last character of the alias value is a blank, then the next command word following the alias is also checked for alias expansion. Therefore, add the following to your .bashrc: alias sudo='sudo ' The space at the end tells bash to look up aliases for the next word. This means that typing sudo foo will lead to 'foo' being looked up as a shell alias. Thank you so much! I've wanted this for a long time. Never knew it was possible. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: homebrew and macports together?
Great job! Thanks! On 4 Jul 2013, at 11:07, Clemens Lang wrote: I am working on a mechanism built into port to prevent problems with homebrew or fink co-installed on the same machine -- Eneko Gotzon Ares ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
