<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 06/01/17 17:37, Adam Dershowitz
wrote:<br>
</div>
<blockquote
cite="mid:E0C5B039-6D3A-4F63-B9DF-A139C8590DF7@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 6, 2017, at 9:49 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=""> 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"><ryandesign@macports.org></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="">https://trac.macports.org/wiki/FAQ#dependonvariant</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>
<br>
Russell<br>
</body>
</html>