> On Jan 6, 2017, at 9:49 AM, Russell Jones <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 <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
