<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 11/01/17 18:04, Adam Dershowitz
wrote:<br>
</div>
<blockquote
cite="mid:54BC0734-A12E-4FB1-83B1-49B352C5071D@alum.mit.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jan 11, 2017, at 10:05 AM, Russell Jones <<a
moz-do-not-send="true"
href="mailto:russell.jones@physics.ox.ac.uk" class=""><a class="moz-txt-link-abbreviated" href="mailto:russell.jones@physics.ox.ac.uk">russell.jones@physics.ox.ac.uk</a></a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<p class=""><br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 06/01/17 17:37, Adam
Dershowitz wrote:<br class="">
</div>
<blockquote
cite="mid:E0C5B039-6D3A-4F63-B9DF-A139C8590DF7@alum.mit.edu"
type="cite" class=""> <br class="">
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jan 6, 2017, at 9:49 AM, Russell
Jones <<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:russell.jones@physics.ox.ac.uk">russell.jones@physics.ox.ac.uk</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""> On
06/01/17 14:28, Adam Dershowitz wrote:<br
class="">
<blockquote
cite="mid:7C26BBC2-17FA-46D2-A60E-0AFB2E90D81D@alum.mit.edu"
type="cite" class="">
<div class="BodyFragment"><font class=""
size="2"><span style="font-size:10pt;"
class="">
<div class="PlainText"><br class="">
<br class="">
> On Jan 6, 2017, at 9:04 AM,
Russell Jones <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:russell.jones@physics.ox.ac.uk"><a class="moz-txt-link-rfc2396E" href="mailto:russell.jones@physics.ox.ac.uk"><russell.jones@physics.ox.ac.uk></a></a>
wrote:<br class="">
> <br class="">
> On 06/01/17 13:22, Adam
Dershowitz wrote:<br class="">
>> On Jan 6, 2017, at 2:20 AM,
Ryan Schmidt <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:ryandesign@macports.org"><a class="moz-txt-link-rfc2396E" href="mailto:ryandesign@macports.org"><ryandesign@macports.org></a></a>
wrote:<br class="">
>>> On Jan 5, 2017, at 09:26,
Adam Dershowitz wrote:<br class="">
>>>> I just tried what you
suggested for py27-numpy and it just
activated without any error.<br
class="">
>>> 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.<br class="">
>>>> So, myports.txt has<br
class="">
>>>> py27-numpy
@1.11.3_0+gfortran (active)
platform='darwin 15' archs='x86_64'<br
class="">
>>>> <br class="">
>>>> And, after the
migration it had installed both that
and the +universal variant.<br
class="">
>>>> 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.<br
class="">
>>>> Any suggestions?<br
class="">
>>> I don't have any answers
for you, beyond the usual reasons why
a port is installed universal, which
are:<br class="">
>>> <br class="">
>>> - you explicitly asked
for it to be installed universal<br
class="">
>>> - you installed another
port universal that depends on this
port<br class="">
>>> - 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))<br class="">
>>> - 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)<br class="">
>> 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.<br class="">
>> 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?<br class="">
>> 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.<br class="">
>> 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.<br class="">
>> <br class="">
>> —Adam<br class="">
> Could you gzip and attach the
list of ports from the old machine and
the output of "port installed
requested"?<br class="">
> <br class="">
> The approach I suggested can't
work, I now realize, as variants
aren't used for working out
dependencies ( <a
moz-do-not-send="true"
href="https://trac.macports.org/wiki/FAQ#dependonvariant"
class=""><a class="moz-txt-link-freetext" href="https://trac.macports.org/wiki/FAQ#dependonvariant">https://trac.macports.org/wiki/FAQ#dependonvariant</a></a>
)<br class="">
> <br class="">
> Russell<br class="">
> <br class="">
<br class="">
<br class="">
Here are the two files. <br class="">
<br class="">
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. <br
class="">
<br class="">
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.
<br class="">
<br class="">
</div>
</span></font></div>
<div class="BodyFragment"><font class=""
size="2"><span style="font-size:10pt;"
class="">
<div class="PlainText"><br class="">
<br class="">
thanks,<br class="">
<br class="">
—Adam</div>
</span></font></div>
</blockquote>
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.<br
class="">
<p class="">Russell<br class="">
</p>
</div>
</div>
</blockquote>
</div>
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.
<div class="">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? </div>
<div class=""><br class="">
</div>
<div class="">—Adam</div>
</blockquote>
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.<br class="">
<br class="">
Russell<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
<div class="">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. </div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">—Adam</div>
<div class=""><br class="">
</div>
</blockquote>
Well, you could try something like this:<br>
port installed | grep '+universal' | sed '<a class="moz-txt-link-abbreviated" href="mailto:s/@.*//">s/@.*//</a>' | xargs -n1 -IXYZ
echo sudo port install XYZ -universal<br>
(remove "echo" if the output looks sane).<br>
<br>
Russell<br>
</body>
</html>