But, if there are actually any ports that I have where +universal is the default, and is necessary, that would break them, and their chain of dependancies. I don’t know if there are any like that, or how I can tell, except by manually reviewing info for each one. Is there any other way?
--Adam > On Jan 12, 2017, at 11:04 AM, Russell Jones <[email protected]> > wrote: > > > > On 11/01/17 18:04, Adam Dershowitz wrote: >> >> >>> On Jan 11, 2017, at 10:05 AM, Russell Jones < >>> <mailto:[email protected]>[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On 06/01/17 17:37, Adam Dershowitz wrote: >>>> >>>> >>>>> On Jan 6, 2017, at 9:49 AM, Russell Jones <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> On 06/01/17 14:28, Adam Dershowitz wrote: >>>>>> >>>>>> >>>>>> > On Jan 6, 2017, at 9:04 AM, Russell Jones >>>>>> > <mailto:[email protected]><[email protected]> >>>>>> > <mailto:[email protected]> wrote: >>>>>> > >>>>>> > On 06/01/17 13:22, Adam Dershowitz wrote: >>>>>> >> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt >>>>>> >> <mailto:[email protected]><[email protected]> >>>>>> >> <mailto:[email protected]> 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 >>>>>> > <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/@.*// <mailto:s/@.*//>' | xargs > -n1 -IXYZ echo sudo port install XYZ -universal > (remove "echo" if the output looks sane). > > Russell
