> On Jan 11, 2017, at 10:05 AM, Russell Jones <russell.jo...@physics.ox.ac.uk> > wrote: > > > > On 06/01/17 17:37, Adam Dershowitz wrote: >> >> >>> On Jan 6, 2017, at 9:49 AM, Russell Jones < >>> <mailto:russell.jo...@physics.ox.ac.uk>russell.jo...@physics.ox.ac.uk >>> <mailto:russell.jo...@physics.ox.ac.uk>> wrote: >>> >>> On 06/01/17 14:28, Adam Dershowitz wrote: >>>> >>>> >>>> > On Jan 6, 2017, at 9:04 AM, Russell Jones >>>> > <mailto:russell.jo...@physics.ox.ac.uk><russell.jo...@physics.ox.ac.uk> >>>> > <mailto:russell.jo...@physics.ox.ac.uk> wrote: >>>> > >>>> > On 06/01/17 13:22, Adam Dershowitz wrote: >>>> >> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt <ryandes...@macports.org> >>>> >> <mailto:ryandes...@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 >>>> > <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
