Migration issue

[Russell Jones]

On 06/01/17 17:37, Adam Dershowitz wrote:
>
>
>> On Jan 6, 2017, at 9:49 AM, Russell Jones 
>> <russell.jones at physics.ox.ac.uk 
>> <mailto:russell.jones at physics.ox.ac.uk>> wrote:
>>
>> On 06/01/17 14:28, Adam Dershowitz wrote:
>>>
>>>
>>> > On Jan 6, 2017, at 9:04 AM, Russell Jones 
>>> <russell.jones at physics.ox.ac.uk> wrote:
>>> >
>>> > On 06/01/17 13:22, Adam Dershowitz wrote:
>>> >> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt 
>>> <ryandesign at macports.org> wrote:
>>> >>> On Jan 5, 2017, at 09:26, Adam Dershowitz wrote:
>>> >>>> I just tried what you suggested for py27-numpy and it just 
>>> activated without any error.
>>> >>> Yes, there will not be an error at activation time. However, if 
>>> you have anything installed that required py27-numpy to be 
>>> universal, it will now be broken.
>>> >>>> So, myports.txt has
>>> >>>>  py27-numpy @1.11.3_0+gfortran (active) platform='darwin 15' 
>>> archs='x86_64'
>>> >>>>
>>> >>>> And, after the migration it had installed both that and the 
>>> +universal variant.
>>> >>>> Yet, when I tried to activate the non-universal version it did 
>>> it without complaint.  So, I really don’t understand why the 
>>> +universal got built at all.
>>> >>>> Any suggestions?
>>> >>> I don't have any answers for you, beyond the usual reasons why a 
>>> port is installed universal, which are:
>>> >>>
>>> >>> - you explicitly asked for it to be installed universal
>>> >>> - you installed another port universal that depends on this port
>>> >>> - you installed another port that is 32-bit only, and you are on 
>>> a 64-bit machine, and the other port depends on this port (You can 
>>> check if the other port says "supported_archs i386 ppc" (or the 
>>> other way around))
>>> >>> - it enables the universal by default, and possibly requires the 
>>> universal variant to be used (You can check the portfile to see if 
>>> "default_variants +universal" appears)
>>> >> What seems really odd to me that I took I moved my myports.txt 
>>> from one machine to another.  So, I used one machine to generate 
>>> that list, and brought it to another machine to build.
>>> >> Both are MacBook pros (one new and one old) and that same list, 
>>> on the new machine, added a bunch of universal ports.  So, I don’t 
>>> see how any of the items in the list above could do that.  If it was 
>>> not universal on the old machine, why would it end up universal on 
>>> the new machine?
>>> >> Could going from 10.11 to 10.12 make something required to be 
>>> universal?  Or could going from Xcode 7 to 8 make a port universal? 
>>> Because otherwise, I just don’t see why they should be different.
>>> >> If anything, I would expect that the newer OS and newer hardware 
>>> should be able to do more things as 64 bit, so would require less 
>>> universal stuff.
>>> >>
>>> >> —Adam
>>> > Could you gzip and attach the list of ports from the old machine 
>>> and the output of "port installed requested"?
>>> >
>>> > The approach I suggested can't work, I now realize, as variants 
>>> aren't used for working out dependencies ( 
>>> https://trac.macports.org/wiki/FAQ#dependonvariant )
>>> >
>>> > Russell
>>> >
>>>
>>>
>>> Here are the two files.
>>>
>>> I don’t believe that I have ever intentionally installed anything 
>>> +universal.  So, I’m fairly sure that anything in this list that is 
>>> universal is because of 3, or 4 above.  But, when I then moved to 
>>> the new machine, it proceeded to make a bunch more things universal.
>>>
>>> As far as I’m concerned pretty much all of my ports should just be 
>>> installed with default variants, so few, if any, should be 
>>> universal. As everything is now working, this is not a big deal.  
>>> But, it does mean that upgrades often must be built, instead of 
>>> using the binary, which would be much faster and use less drive space.
>>>
>>>
>>>
>>> thanks,
>>>
>>> —Adam
>> It looks like the extra +universal stuff comes from the things that 
>> were marked +universal installing all their dependencies +universal, 
>> which is expected behaviour. It looks like the restore script just 
>> installs the things listed in the order given, so doesn't preserve 
>> the variants exactly (+universal satisfies a request to install with 
>> no variants, I think, though I'm unsure). You could search and 
>> replace +universal (i.e. remove all instances of it) in myports, then 
>> tear-down and redo the install, I guess.
>>
>> Russell
>>
> But, this list is from the old machine.  My question is why the new 
> machine ended up with a lot more +universal.  For example, the list 
> that I sent does not have +universal for py27-numpy, while the new 
> machine, that I used the above list to install, did end up with 
> +universal.
> If the prior machine did not require +universal, based on the 
> dependency tree, why would the new machine require it?  Or was 
> something broken on the old machine, where it really did require 
> +universal, but never actually installed it that way, and I happened 
> never to hit that bug?
>
> —Adam
Well, in the scenario I'm thinking of, it would be because something was 
built +universal that depended on py27-numpy before py27-numpy was 
checked for whether it's installed by itself. It's possible to install 
programs -universal that are depended on by others that are +universal 
without error or warning, as you've seen. It also seems that link 
checking doesn't pick it up. I'm not sure how one goes about using the 
32-bit portions of programs (as opposed to linking 32-bit binaries 
against them, which you do with the -m32 flag, IIRC) where the program 
is not 32-bit only. So it's possible you only ever used the 64-bit 
portions of the binaries and so didn't see any problems. I'll happily 
concede something else may be going on.

Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20170111/e8f3b413/attachment.html>