Macports does what I want (?) not what I say

[Ryan Schmidt]

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.