Re: How add variant when upgrading octave

[list_email]

On May 16, 2016, at 6:27 AM, Joshua Root  wrote:

> Murray Eisenberg wrote:
>> Currently installed and active is:
>> 
>>   octave @3.8.2_18+atlas+gcc48+glgui
>> 
>> This is flagged as having available upgrade to 4.0.2_0, so I executed...
>> 
>>  sudo port upgrade octave
>> 
>> …which generated the error:
>> 
>> Error: org.macports.fetch for port octave returned: must set at least 
>> one Fortran variant
>> 
>> Presumably I want to add fortran
>> 
>> Is there some form of the upgrade command to do that?
>> 
>> Or do I simply have to do a new install:
>> 
>>   sudo port install octave @4.0.2_0+atlas+gcc48+glgui+gfortran
> 
> I think you want to do:
> 
> sudo port upgrade octave +gfortran
> 
> which will add gfortran to the currently installed set of variants while 
> upgrading.
> 
> Having to manually intervene during an upgrade like this is of course poor 
> UX. The problem here is that the gcc48 variant (actually all of gcc44, gcc45, 
> gcc46, gcc47, gcc48, gcc49) was removed rather than sticking around as a 
> "legacy compatibility variant" that just causes a mandatory replacement 
> variant (presumably +gfortran here) to be selected.
> 
> - Josh

I just had the same problem (again!). When I do 

sudo port upgrade octave +gfortran

As Josh suggests, I get

Error: fftw-3: Variant gcc48 conflicts with gfortran
Error: Unable to open port: Error evaluating variants

Now what?

Jerry

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Getting rid of port binaries in /software

[Clemens Lang]

Hi,

On Tue, May 17, 2016 at 06:38:24PM -0400, Nicolas Martin wrote:
> > If you delete those archives you can no longer deactivate and
> > re-activate a port. In addition to the use case above, this is also
> > helpful when one of the files installed by the port was corrupted
> > for some reason -- just de- and re-activate it.
> 
> I suppose that if I were to manually delete those archives, MacPorts
> would not be so kind as to detect this and just start the build
> process over again, if he needs to?

I thought about this earlier but then ended up forgetting to mention it
in my initial reply: Deleting these archive files may trick an old
script that was used to do the transition towards the archive-based
approach into thinking that you're doing a migration from an old
macports version when you run selfupdate. If that's the case, it will
try to re-create the archives you deleted from the files you have on
disk, which will fail.

Since a couple of people ran into this before without asking on the list
on possible side-effects, I think we should actually remove this upgrade
code path soonish. It's been years since MacPorts 1.8 (?) that
introduced this change, and it's unlikely that anybody still has a
working 1.8 installation they want to upgrade.

-- 
Clemens
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Getting rid of port binaries in /software

[Clemens Lang]

Hi,

On Wed, May 18, 2016 at 07:14:49PM -0400, Brandon Allbery wrote:
> > Would it be safe then to have some of /opt/local/var/macports
> > symlink-ed on an external hard drive ?
> 
> I used to do this on my MacBook Air. One trick was to have .../sources
> symlinked as well as .../software and .../build; this meant port
> sync/install/activate/deactivate and friends failed safely if I didn't
> have the drive attached. (I don't know if this is still true; haven't
> used it in a while, and there have been a few updates to MacPorts
> itself since then.)

I haven't seen the code paths that use these foldes change a lot
recently, so you should be fine.

-- 
Clemens
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: port reclaim use

[Clemens Lang]

Hi,

On Tue, May 17, 2016 at 08:21:09PM -0700, list_em...@icloud.com wrote:
> I hate giant blobs on my hard disk that don't do anything, so I'm
> wondering if 
> 
> port reclaim
> 
> is a safe and effective way of reducing the 13.7 GB size of my
> MacPorts installation.

As far as I know port reclaim is only in development versions of
MacPorts at the moment and has not found its way into a released version
yet. This of course means that you might have to expect the occasional
bug or two, but overall I think the reclaim code is pretty well tested
by now.

Reclaim does two things: First, it does the equivalent of uninstall
inactive, and then it locates all source code files that are no longer
used by any of your installed ports and offers to delete them. I don't
use the first part of the functionality (because I usually do uninstall
inactive manually), but I can vouch that the second part works well in
current trunk.

Additionally, may I suggest port_cutleaves (available in the equally
named port) to save more disk space on things you no longer need?

-- 
Clemens
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Getting rid of port binaries in /software

[Brandon Allbery]

On Tue, May 17, 2016 at 6:38 PM, Nicolas Martin  wrote:

> Would it be safe then to have some of /opt/local/var/macports symlink-ed
> on an external hard drive ?


I used to do this on my MacBook Air. One trick was to have .../sources
symlinked as well as .../software and .../build; this meant port
sync/install/activate/deactivate and friends failed safely if I didn't have
the drive attached. (I don't know if this is still true; haven't used it in
a while, and there have been a few updates to MacPorts itself since then.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Getting rid of port binaries in /software

[Mojca Miklavec]

On 19 May 2016 at 00:25, Eric A. Borisch wrote:
> If you are just looking to save some space at the expense of time, you could
> set:
>
> portarchivetype  txz
>
> in macports.conf; on some of the big clang/llvm archives this is ~2x
> improvement...

But in current implementation that probably means that all the
packages have to be compiled locally?

Mojca
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Getting rid of port binaries in /software

[Eric A. Borisch]

If you are just looking to save some space at the expense of time, you
could set:

portarchivetype  txz

in macports.conf; on some of the big clang/llvm archives this is ~2x
improvement...

On Wed, May 18, 2016 at 12:16 PM, Ryan Schmidt > wrote:
>
>> On May 17, 2016, at 5:38 PM, Nicolas Martin > wrote:
>>
>>>
>>> On May 17, 2016, at 5:15 PM, Clemens Lang > wrote:
>>>
>>> On Tue, May 17, 2016 at 10:58:56AM -0400, Nicolas Martin wrote:
 I have looked for real answers regarding this question through the
 mailing list, but did not really understand the purpose of these
 files.
>>>
>>> MacPorts always keeps a tarball of the files installed by a certain
>>> port in this directory. This allows you to switch between installed
>>> versions or between ports that would otherwise conflict without
>>> re-installing them completely. port activate/port deactivate implement
>>> this.
>>
>> Is there a way to have MacPorts behave so as to completely reinstall a
port if one needs to ?
>
> Regarding switching between installed versions of a port: MacPorts does
not have the capability to build an arbitrary version of a port, only the
current version of a port. So if you might want to switch back to an older
version, you should keep it installed. Otherwise you have to perform manual
steps to rebuild the old version as described here:
>
> https://trac.macports.org/wiki/howto/InstallingOlderPort
>
> Regarding switching between conflicting ports: If you don't want to keep
both ports installed, for example for disk space reasons, you can of course
uninstall one port and install the other. Then, to switch back, you can
uninstall the second port and reinstall the first.
>
>
>> I would prefer to wait through the process of building and activating
the port again if I need to, than to lose quite a lot of space with
duplicated binaries I almost never have to activate again.
>>
>>> The rationale here is that after an update you can test the updated
>>> version of a software for a while, and if you notice it causes problems
>>> you can file a ticket and easily go back to the old version with a
>>> simple
>>> sudo port activate @oldversion
>>
>> I understand this, but if you never have to revert to an older version
of a package, this is quite a waste of space.
>
> It's also not entirely uncommon for a user to discover that some of a
port's files have vanished or been replaced with the wrong contents, for
example by running a third-party installer that installed older files into
the MacPorts prefix. Some of these types of problems can be resolved by
deactivating and then reactivating the affected ports, which you couldn't
do if you didn't have an archive there.
>
> The decision to store these archives on the disk was made with the
assumption that disk space is cheap, and becoming cheaper. And while disk
space is indeed getting cheaper, we didn't anticipate the rise of
more-expensive-yet-smaller SSDs.
>
>>
>>>
>>> MacPorts used to keep these files in a directory and just hard-link them
>>> into $prefix, but that (a) means modifications to files in $prefix
>>> affect the supposed-to-be prinstine copy, and (b) isn't easy to download
>>> as pre-built binary. For this reason, we switched to tarballs a while
>>> back and now provide pre-built binaries for some of these tar balls.
>
> Another reason was that hard links didn't play nicely with Time Machine.
>
>
 I have almost 5Gb of archives (tbz2) in
 /opt/local/var/macports/software.
>>>
>>> You seem to have quite a few ports installed. My software directory is
>>> 3.4G with 652 installed ports.
>>
>> Well clang and llvm occupies a whooping 1.2G by themselves alone.
>
> True, clang and llvm are large. But according to
>
> https://packages.macports.org/llvm-3.7/?C=M;O=D
>
> llvm-3.7 is 377MB and according to
>
> https://packages.macports.org/clang-3.7/?C=M;O=D
>
> clang-3.7 is 357MB. If you're seeing twice that size on your system,
maybe you've installed it with the universal variant.
>
>
 I have already run the port uninstall inactive command, so from my
 understanding, what remains in this path is from currently active and
 used ports.
>>>
>>> Correct.
>>>
 What I don’t understand, and does not seem to be clear from any posts
 I have read regarding the matter, is why should these archives be
 kept?
>>>
>>> If you delete those archives you can no longer deactivate and
>>> re-activate a port. In addition to the use case above, this is also
>>> helpful when one of the files installed by the port was corrupted for
>>> some reason -- just de- and re-activate it.
>>
>> I suppose that if I were to manually delete those archives, MacPorts
would not be so kind as to detect this and just start the build process
over again, if he needs to ?
>
> Deactivating a port for which you've deleted the archive would probably
succeed, since the information 

Re: gcc-6

[Jean-François Caron]

I have an unfounded opinion about this:

> Naturally a hypothetical gcc6 port that only provides a Fortran compiler 
> would take less space and less time to build than one that also provides C, 
> C++, and Java compilers.


I’m not an expert on this at all, but from what I understand the only 
language-dependent part of the compiler is the front-end.  This bit takes your 
input language (C++, Fortran, whatevs) and turns it into some internal 
representation.  Much of the heavy work of optimization, analysis, and 
code-generation happens on the internal representation, which is independent of 
the source language.

Thus splitting gcc into separate ports for different languages would end up 
duplicating most of the actual machinery in gcc.  Conversely, removing specific 
languages from gcc wouldn’t reduce the size by that much.

Has anyone tried building gcc with just one or a few languages supported, and 
see the difference in size (or self-compilation time)?  Does it really make a 
difference?  I’d expect maybe a 20-30% size reduction if you left only C++ 
compared to including all the supported languages.

JF
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: gcc-6

[Ryan Schmidt]

> On May 17, 2016, at 6:07 AM, René J.V. Bertin  wrote:
> 
> On a related note: would it be very hard to set up the gcc port(s) such that 
> users can indicate which languages they wish to use the compiler for? IIRC 
> gcc's configure script allows you to do just that via an option that receives 
> a list of language codes, so it would guess that language variants could 
> simply construct that option.
> A gcc build that only provides fortran (and/or Ada) should be considerably 
> leaner than a build that provides everything, no?

Naturally a hypothetical gcc6 port that only provides a Fortran compiler would 
take less space and less time to build than one that also provides C, C++, and 
Java compilers. But then other ports that expect C, C++ or Java compilers to 
exist in the gcc6 port would fail to work. Other ports need to be able to 
declare a dependency on another port and be assured that the port contains the 
things they need.

Using variants to enable different languages is therefore not workable because 
MacPorts does not have the capability to declare dependencies on a variant of 
another port. So the only possible way it might work is by creating a subport 
for each language.

Besides that being a lot of work, I don't know if the gcc build system is 
arranged so that building different languages separately is possible. We 
separated libgcc into a subport some time ago, but that works by having both 
the libgcc port and the gccN port build everything, then delete the parts that 
aren't needed in the post-destroot phase, which is wasteful and makes the build 
take twice as long as it used to before the separation (but this separation is 
useful and so we tolerate this added build time, which is also mitigated by 
having binaries available from the buildbot). If the build system cannot 
accommodate building languages separately, having a subport for each language 
could quickly balloon the build times for the gccN ports.

The gcc build uses a 3-stage process, which, as I understand it, includes 
compiling the compiler, then using the compiler to compile itself again. That 
means the compiler for all languages used to write the compiler itself would be 
needed.

Building a compiler is a complicated affair, and the gcc6 portfile is already 
over 260 lines long. I don't really want to complicate it further. Not to 
mention that a build takes hours, so making and testing any extensive changes 
would be extremely time consuming.


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Getting rid of port binaries in /software

[Ryan Schmidt]

> On May 17, 2016, at 5:38 PM, Nicolas Martin  
> wrote:
> 
>> 
>> On May 17, 2016, at 5:15 PM, Clemens Lang  wrote:
>> 
>> On Tue, May 17, 2016 at 10:58:56AM -0400, Nicolas Martin wrote:
>>> I have looked for real answers regarding this question through the
>>> mailing list, but did not really understand the purpose of these
>>> files.
>> 
>> MacPorts always keeps a tarball of the files installed by a certain
>> port in this directory. This allows you to switch between installed
>> versions or between ports that would otherwise conflict without
>> re-installing them completely. port activate/port deactivate implement
>> this.
> 
> Is there a way to have MacPorts behave so as to completely reinstall a port 
> if one needs to ? 

Regarding switching between installed versions of a port: MacPorts does not 
have the capability to build an arbitrary version of a port, only the current 
version of a port. So if you might want to switch back to an older version, you 
should keep it installed. Otherwise you have to perform manual steps to rebuild 
the old version as described here:

https://trac.macports.org/wiki/howto/InstallingOlderPort

Regarding switching between conflicting ports: If you don't want to keep both 
ports installed, for example for disk space reasons, you can of course 
uninstall one port and install the other. Then, to switch back, you can 
uninstall the second port and reinstall the first.


> I would prefer to wait through the process of building and activating the 
> port again if I need to, than to lose quite a lot of space with duplicated 
> binaries I almost never have to activate again.
> 
>> The rationale here is that after an update you can test the updated
>> version of a software for a while, and if you notice it causes problems
>> you can file a ticket and easily go back to the old version with a
>> simple
>> sudo port activate @oldversion
> 
> I understand this, but if you never have to revert to an older version of a 
> package, this is quite a waste of space.

It's also not entirely uncommon for a user to discover that some of a port's 
files have vanished or been replaced with the wrong contents, for example by 
running a third-party installer that installed older files into the MacPorts 
prefix. Some of these types of problems can be resolved by deactivating and 
then reactivating the affected ports, which you couldn't do if you didn't have 
an archive there.

The decision to store these archives on the disk was made with the assumption 
that disk space is cheap, and becoming cheaper. And while disk space is indeed 
getting cheaper, we didn't anticipate the rise of more-expensive-yet-smaller 
SSDs.

> 
>> 
>> MacPorts used to keep these files in a directory and just hard-link them
>> into $prefix, but that (a) means modifications to files in $prefix
>> affect the supposed-to-be prinstine copy, and (b) isn't easy to download
>> as pre-built binary. For this reason, we switched to tarballs a while
>> back and now provide pre-built binaries for some of these tar balls.

Another reason was that hard links didn't play nicely with Time Machine.


>>> I have almost 5Gb of archives (tbz2) in
>>> /opt/local/var/macports/software.
>> 
>> You seem to have quite a few ports installed. My software directory is
>> 3.4G with 652 installed ports.
> 
> Well clang and llvm occupies a whooping 1.2G by themselves alone.

True, clang and llvm are large. But according to

https://packages.macports.org/llvm-3.7/?C=M;O=D

llvm-3.7 is 377MB and according to

https://packages.macports.org/clang-3.7/?C=M;O=D

clang-3.7 is 357MB. If you're seeing twice that size on your system, maybe 
you've installed it with the universal variant.


>>> I have already run the port uninstall inactive command, so from my
>>> understanding, what remains in this path is from currently active and
>>> used ports.
>> 
>> Correct.
>> 
>>> What I don’t understand, and does not seem to be clear from any posts
>>> I have read regarding the matter, is why should these archives be
>>> kept?
>> 
>> If you delete those archives you can no longer deactivate and
>> re-activate a port. In addition to the use case above, this is also
>> helpful when one of the files installed by the port was corrupted for
>> some reason -- just de- and re-activate it.
> 
> I suppose that if I were to manually delete those archives, MacPorts would 
> not be so kind as to detect this and just start the build process over again, 
> if he needs to ?

Deactivating a port for which you've deleted the archive would probably 
succeed, since the information about what files to remove comes from the 
registry and not from the archive, but attempting to reactivate it would 
probably give you an error message. Manually removing archives of installed 
ports from the software directory is not something we support at this time. 
MacPorts does not expect you to do that, and its behavior if you do is 
undefined.


> Would