Migration issue

[Russell Jones]

On 11/01/17 18:04, Adam Dershowitz wrote:
>
>
>> On Jan 11, 2017, at 10:05 AM, Russell Jones 
>> <russell.jones at physics.ox.ac.uk 
>> <mailto:russell.jones at physics.ox.ac.uk>> wrote:
>>
>>
>>
>> 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> 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
>
> If you are correct is there any way to fix it?  One option would be to 
> uninstall everything and then to avoid the migration script, and just 
> to reinstall my list of requested ports and see what happens.  But, 
> that will take some time.  Especially, since a good number of ports 
> end up building from source instead of binaries.  But, it could be 
> that the reason for this is that they ended up being +universal, so 
> they were not available on the buildbots.
> It does seem odd that gcc6, which is only a build dependancies, is 
> building +universal, as I would not expect that a compiler would have 
> to match what it is building (32 bit v 64 bit).  the only port that it 
> is needed to build and shows up as universal is py27-numpy.  So, I 
> would guess that is why it then gets forced to be universal.
>
> —Adam
>
Well, you could try something like this:
port installed | grep '+universal' | sed 's/@.*//' | xargs -n1 -IXYZ 
echo sudo port install XYZ -universal
(remove "echo" if the output looks sane).

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