Re: Migration issue

[Adam Dershowitz]

> On Jan 13, 2017, at 10:58 AM, Daniel J. Luke  wrote:
> 
>> So, this suggests that there might be some combination of the long list of 
>> ports below that I could uninstall +universal, then install default, and 
>> that might allow wine to build? 
> 
> well, I was suggesting that you can even 'uninstall' any 'build' dependencies 
> after they've been used to build something (since they're not needed at 
> runtime).
> 
> you probably shouldn't care too much about what is or isn't installed 
> +universal if your ports are working, though.

I really was initially worried because there were some build issues.  Then, was 
also very curious why two different machines would not end up with the same 
universal or not, for the same set of ports.  It sounds like the answer, is 
that the variants that are installed depend on the install order.  The other 
reason that I considered is that when not installing the default versions the 
machine can’t use binaries, which is a nice convenience for install time etc.  



> 
>> But, no easy way to figure out which combination?  Macports might or might 
>> not want to update any given port to +universal?  
>> 
>> At the moment my libunistring is not +universal.  Although, perhaps the 
>> reasons that macports wants to rebuild textlive that way, is that it can 
>> rebuild that as well.
> 
> to get your stuff working, you could probably uninstall libunistring, install 
> textlive (non-universal) and then install libunistring +universal while 
> telling MacPorts not to look at dependencies (-n) [although I haven't tested 
> that, so it might not work since IIRC the build_arch +universal stuff is 
> 'special']
> 
> -- 
> Daniel J. Luke
> 
> 
> 

That seemed to do the job.  
Just to be clear, for anyone else who is having this issue.  I had to force the 
uninstall:
sudo port -f uninstall libunistring
Then do the installs:
sudo port clean texlive-bin
sudo port  install texlive-bin

This install found gnutils to be a broken ports, and it fixed it by installing 
libunistring (default)
Then, I switched it to universal:

sudo port install -n libunistring +universal
(this also installed texlive-basic)

Finally, I was able to install wine-devel successfully:
sudo port install wine-devel

Thank you for all of the assistance getting it working.

—Adam

Re: Migration issue

[Daniel J. Luke]

> So, this suggests that there might be some combination of the long list of 
> ports below that I could uninstall +universal, then install default, and that 
> might allow wine to build? 

well, I was suggesting that you can even 'uninstall' any 'build' dependencies 
after they've been used to build something (since they're not needed at 
runtime).

you probably shouldn't care too much about what is or isn't installed 
+universal if your ports are working, though.

> But, no easy way to figure out which combination?  Macports might or might 
> not want to update any given port to +universal?  
> 
> At the moment my libunistring is not +universal.  Although, perhaps the 
> reasons that macports wants to rebuild textlive that way, is that it can 
> rebuild that as well.

to get your stuff working, you could probably uninstall libunistring, install 
textlive (non-universal) and then install libunistring +universal while telling 
MacPorts not to look at dependencies (-n) [although I haven't tested that, so 
it might not work since IIRC the build_arch +universal stuff is 'special']

-- 
Daniel J. Luke

Re: Migration issue

[Daniel J. Luke]

On Jan 13, 2017, at 9:50 AM, Adam Dershowitz  wrote:
>> The dependency engine in MacPorts doesn't really handle variants, so I 
>> always expect everything that does magic with variants to have problems like 
>> this (the difference in +universal ports probably just depends on the order 
>> that things were installed, when they're being pulled in as a dependency of 
>> something that is +universal, they get +universal when they might not get it 
>> if they were installed already).
> 
> So does that mean that if I happened to have first installed texlive-bin 
> (default), and then tried to install wine that it might have left that 
> version alone?  And that it would work?  

maybe?

Want to try it and report back?

> But, that because it was being installed, explicitly as a dependent that it 
> builds it +universal?  So, the fix might be for to manually install it with 
> default settings?  Or will that necessarily break wine-devel, since that 
> needs to be i386?

I don't use either, so I can't tell you if it will work or not - but I suspect 
it might (wine-devel needs gnutls which needs libunistring which pulls in 
textlive - the gnutls and libunistring libraries probably need to be universal, 
textlive is just a build dependency of libunistring, so you could uninstall it 
after libunistring is installled and it should still work):

% port rdeps wine-devel
The following ports are dependencies of wine-devel @2.0-rc4_0:
  bison
xz
  libiconv
gperf
  gettext
expat
ncurses
perl5
  perl5.24
gdbm
m4
bison-runtime
  flex
  pkgconfig
  fontconfig
freetype
  bzip2
  libpng
zlib
  gstreamer1
gzip
  texinfo
help2man
  p5.24-locale-gettext
autoconf
automake
libtool
glib2
  libxml2
  libffi
  pcre
libedit
gtk3
  atk
gobject-introspection
  cairo
libpixman
xrender
  xorg-libX11
xorg-xtrans
xorg-bigreqsproto
xorg-xcmiscproto
xorg-xextproto
xorg-xf86bigfontproto
xorg-inputproto
xorg-util-macros
xorg-libXdmcp
  xorg-xproto
xorg-libXau
xorg-libxcb
  xorg-xcb-proto
python27
  openssl
  sqlite3
  db48
  python_select
  python2_select
  xorg-libpthread-stubs
xorg-kbproto
  xorg-renderproto
xorg-libXext
xorg-xcb-util
  py27-mako
py27-setuptools
  unzip
py27-beaker
py27-markupsafe
  pango
harfbuzz
  graphite2
cmake
  curl
curl-ca-bundle
  libarchive
lzo2
  libuv
Xft2
  gdk-pixbuf2
shared-mime-info
  intltool
gnome-common
  autoconf-archive
p5.24-getopt-long
p5.24-pathtools
p5.24-scalar-list-utils
p5.24-xml-parser
  p5.24-libwww-perl
p5.24-encode-locale
p5.24-file-listing
  p5.24-http-date
p5.24-html-form
  p5.24-html-parser
p5.24-html-tagset
  p5.24-http-message
p5.24-io-html
p5.24-lwp-mediatypes
p5.24-uri
  p5.24-mime-base64
p5.24-http-cookies
p5.24-http-daemon
p5.24-http-negotiate
p5.24-net-http
  p5.24-io-socket-ssl
p5.24-io-socket-inet6
  p5.24-socket6
  p5.24-io
p5.24-io-socket-ip
  p5.24-socket
p5.24-mozilla-ca
p5.24-net-libidn
  libidn
p5.24-net-ssleay
  p5.24-test-exception
p5.24-sub-uplevel
  p5.24-test-nowarnings
  p5.24-test-warn
p5.24-www-robotrules
p5.24-lwp-protocol-https
jasper
  jpeg
tiff
  libepoxy
mesa
  gindent
  py27-libxml2
  xorg-glproto
  xorg-dri2proto
  xorg-libXdamage
xorg-libXfixes
  xorg-fixesproto
xorg-damageproto
  xorg-libXi
  xorg-libXmu
xorg-libXt
  xorg-libsm
xorg-libice
  xorg-libXxf86vm
xorg-xf86vidmodeproto
python34
  python3_select
  xorg-libXrandr
xorg-randrproto
 

Re: Migration issue

[Adam Dershowitz]

> On Jan 11, 2017, at 10:05 AM, Russell Jones  
> wrote:
> 
> 
> 
> On 06/01/17 17:37, Adam Dershowitz wrote:
>> 
>> 
>>> 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  
 >  
 >  wrote:
 > 
 > On 06/01/17 13:22, Adam Dershowitz wrote:
 >> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt  
 >>  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 

Re: Migration issue

[Russell Jones]

On 06/01/17 17:37, Adam Dershowitz wrote:



On Jan 6, 2017, at 9:49 AM, Russell Jones 
> wrote:


On 06/01/17 14:28, Adam Dershowitz wrote:



> On Jan 6, 2017, at 9:04 AM, Russell Jones 
 wrote:

>
> On 06/01/17 13:22, Adam Dershowitz wrote:
>> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt 
 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 

Re: Migration issue

[Brandon Allbery]

On Fri, Jan 6, 2017 at 12:37 PM, Adam Dershowitz  wrote:

> But, this list is from the old machine.  My question is why the new
> machine ended up with a lot more +universal.


Actually, I'm starting to wonder if there is a general option leakage issue
of late (compare the discussion about archive_sites leaking).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: Migration issue

[Adam Dershowitz]

> On Jan 6, 2017, at 9:49 AM, Russell Jones  
> wrote:
> 
> On 06/01/17 14:28, Adam Dershowitz wrote:
>> 
>> 
>> > On Jan 6, 2017, at 9:04 AM, Russell Jones  
>> >  wrote:
>> > 
>> > On 06/01/17 13:22, Adam Dershowitz wrote:
>> >> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt  
>> >>  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 

Re: Migration issue

[Russell Jones]

On 06/01/17 14:28, Adam Dershowitz wrote:



> On Jan 6, 2017, at 9:04 AM, Russell Jones 
 wrote:

>
> On 06/01/17 13:22, Adam Dershowitz wrote:
>> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt  
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

Re: Migration issue

[Russell Jones]

On 06/01/17 13:22, Adam Dershowitz wrote:

On Jan 6, 2017, at 2:20 AM, Ryan Schmidt  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

Re: Migration issue

[Adam Dershowitz]

> On Jan 6, 2017, at 2:20 AM, Ryan Schmidt  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

Re: Migration issue

[Ryan Schmidt]

> 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)

Re: Migration issue

[Russell Jones]

You could try activating the non +universal version to get a dependency 
error. Then do the same for the dependency, and so on back to the first 
port built +universal.


Russell


On 05/01/17 14:56, Adam Dershowitz wrote:



On Jan 5, 2017, at 9:44 AM, Rainer Müller > wrote:


On 2017-01-05 14:51, Adam Dershowitz wrote:



On Jan 4, 2017, at 10:02 PM, Ryan Schmidt > wrote:


On Jan 4, 2017, at 07:52, Adam Dershowitz wrote:

So, yes it seems that the on the new machine I ended up with gcc6 
being universal, so then cctools, ld64-latest, llvm-3.9 etc are 
all universal.  But, the strange thing is that gcc6 has no 
dependents, and I didn’t explicitly install it.  So, I’m not sure 
what caused it to be installed.  And, on the new machine it, and 
the chain down, installed +universal, while on the older machine 
it installed the default variant.  Both computers installed gcc6 
6.2.0_2.
So, my academic question is why did this happen?  And, the related 
questions are what port would have installed gcc6? Since I see this:

$port dependents gcc6
gcc6 has no dependents.


I don't know. If you don't need gcc6, don't install it / uninstall it.


It appears that build dependencies don’t show up with the 
dependencies command?  So, some installed port might have required 
gcc6 to install, but doesn’t need it for runtime.


Try with this:

 port echo depends_build:gcc6 and installed

This is only using the information from the latest ports tree, but could
probably answer your question.

Rainer


Thanks that helps.  It is a step in the right direction, but still 
leaves my question about what generates all the extra universal builds 
on the new machine, when the old machine had mostly default.
For example, on the new machine the above shows that py27-numpy has 
two installs, with the active one being +universal.  So, the migrate 
script first installed it default, then due to yet another port, must 
have rebuilt it +universal.  But, I don’t know how to trace those back 
to the root of it.
Perhaps the least effort would be to remove +universal completely from 
myports.txt then uninstall everything, and then reinstall with the 
migrate script?  Would anything that needs to be universal then end up 
getting put back that way?

Re: Migration issue

[Adam Dershowitz]

> On Jan 5, 2017, at 9:44 AM, Rainer Müller  wrote:
> 
> On 2017-01-05 14:51, Adam Dershowitz wrote:
>> 
>> 
>>> On Jan 4, 2017, at 10:02 PM, Ryan Schmidt  wrote:
>>> 
>>> On Jan 4, 2017, at 07:52, Adam Dershowitz wrote:
>>> 
 So, yes it seems that the on the new machine I ended up with gcc6 being 
 universal, so then cctools, ld64-latest, llvm-3.9 etc are all universal.  
 But, the strange thing is that gcc6 has no dependents, and I didn’t 
 explicitly install it.  So, I’m not sure what caused it to be installed.  
 And, on the new machine it, and the chain down, installed +universal, 
 while on the older machine it installed the default variant.  Both 
 computers installed gcc6 6.2.0_2.  
 So, my academic question is why did this happen?  And, the related 
 questions are what port would have installed gcc6? Since I see this:
 $port dependents gcc6
 gcc6 has no dependents.
>>> 
>>> I don't know. If you don't need gcc6, don't install it / uninstall it.
>> 
>> It appears that build dependencies don’t show up with the dependencies 
>> command?  So, some installed port might have required gcc6 to install, but 
>> doesn’t need it for runtime.  
> 
> Try with this:
> 
>  port echo depends_build:gcc6 and installed
> 
> This is only using the information from the latest ports tree, but could
> probably answer your question.
> 
> Rainer

Thanks that helps.  It is a step in the right direction, but still leaves my 
question about what generates all the extra universal builds on the new 
machine, when the old machine had mostly default.
For example, on the new machine the above shows that py27-numpy has two 
installs, with the active one being +universal.  So, the migrate script first 
installed it default, then due to yet another port, must have rebuilt it 
+universal.  But, I don’t know how to trace those back to the root of it.  
Perhaps the least effort would be to remove +universal completely from 
myports.txt then uninstall everything, and then reinstall with the migrate 
script?  Would anything that needs to be universal then end up getting put back 
that way?