Re: problem with reactivating ports
> On Jan 14, 2019, at 08:34, Bill Cole > wrote: > > On 14 Jan 2019, at 2:46, Werner LEMBERG wrote: > >> Hello Ryan! >> >> >>> Do you need those old inactive versions? If not, you could >>> uninstall the inactive ports before beginning the exercise. >> >> Is there a safe command to uninstall all inactive ports in one rush? > > This is one of the 3 housekeeping tasks that 'port reclaim' performs (with > prompting for each step.) or you can just do "port uninstall installed and > not active" for just cleaning out inactive ports. "not active" - "inactive" works too. And "active" or "inactive" seems to imply "installed" anyway. I'd say "port uninstall inactive and not requested" most of the time (safer), and just "port install inactive" once in awhile, esp. when there was nothing that was failing to update, and no other reason I anticipated wanting to fall back to an older version of a requested port. sh-3.2# port echo inactive and requested|wc -l 11 sh-3.2# port echo requested|wc -l 330 sh-3.2# port echo inactive|wc -l 51 sh-3.2# port echo inactive and not requested|wc -l 40 I gather that the last of those is older versions of dependencies of requested ports. And that it's been awhile since I cleaned out old stuff. :-)
Re: problem with reactivating ports
On 14 Jan 2019, at 2:46, Werner LEMBERG wrote: Hello Ryan! Do you need those old inactive versions? If not, you could uninstall the inactive ports before beginning the exercise. Is there a safe command to uninstall all inactive ports in one rush? This is one of the 3 housekeeping tasks that 'port reclaim' performs (with prompting for each step.) or you can just do "port uninstall installed and not active" for just cleaning out inactive ports. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Available For Hire: https://linkedin.com/in/billcole
Re: problem with reactivating ports
Hello Ryan! > Do you need those old inactive versions? If not, you could > uninstall the inactive ports before beginning the exercise. Is there a safe command to uninstall all inactive ports in one rush? >> Irrespective of the problems I wonder whether it is a valid >> approach to deactivate everything – since `port' started with zero >> packages at the very beginning, it should work, right? > > Yes, deactivating all ports should work successfully. We do that on > the buildbot workers after every build. Verified thanks, after building `port' with an external curl library (I used https://try.gitea.io/donbright/lm for my Lion box). >> Ah, my fault, I was imprecise: `port' complained not being able to >> deactivate `libgcc8' because it wasn't active. This implies that >> `port' has implicitly already deactivated it and then stumbled over >> the direct command to deactivate. > > I have seen this error with libgcc8 on the buildbot workers as well. > I think we probably forgot a step back when the libgcc7/libgcc8 > ports were introduced. For example, we may have forgotten to > increase the revision of all the ports that depend on those ports. OK, thanks for the info. > Of course, macOS is not GNU/Linux and there are some differences. > For example, whereas GNU/Linux uses its package manager to install > everything, macOS comes with libraries like libcurl that are not > managed by a package manager and we use them. There is no need to > link with them statically, nor do we want to, for all the usual > reasons: If that library is ever updated by Apple, we would not > benefit from that update. Well, this is true for MacOS versions still supported by Apple, but not for older ones. I'm glad that MacPorts is on the conservative side. For the young kids who always use the newest stuff there is Homebrew... > The problem only arises when you do something unsupported, like > linking MacPorts to libraries it itself installed. Please don't do > that! :) Lesson learned :-) > I continue to believe that we should bundle a recent version of curl > and libressl with MacPorts to avoid the too-old-openssl problem that > we see on older macOS systems, but we have not reached consensus > that we want to do that. See https://trac.macports.org/ticket/51516 Yes! Actually, I don't understand the many objections raised in the ticket. For older MacOS versions, `macports-base' could be configured to build private, statically linked libcurl & ssl versions only once, namely for `port' itself – let's call the resulting binary `port-bootstrap' –, and there would be no need to always use the most recent and most secure versions since you only use it to start MacPorts package management. The first action could be then to download a `port' package (which doesn't exist yet) that uses the most recent libraries, and which receives the usual updates. If someone is going to delete that `port' package accidentally, the original `port-bootstrap' binary would be still available as a backup. >> I want to document how to build. Compiling all lilypond flavours >> from scratch (including documentation) takes almost a day (using >> approx. 20GByte of disk space), so it is quite important to know >> what MacPorts packages must be installed before starting >> compilation for obvious reasons. [...] > > I don't think there's a good way to figure that out automatically. > [...] OK, thanks. Werner
Re: problem with reactivating ports
On Jan 13, 2019, at 10:03, Werner LEMBERG wrote: > It's simpler, yes, but why is it `much better'? As far as I > understand, later on I can't simply say > > sudo port activate inactive > > since the list of inactive ports is much larger due to updates. In > other words, I have to store the list of active packages somewhere. What you did -- recording active files into a text file for later reactivation -- is fine, and is similar to what we recommend users do in our migration instructions. Do you need those old inactive versions? If not, you could uninstall the inactive ports before beginning the exercise. However, keeping a record in a text file, as you did, is still a good idea, in case anything goes wrong and the complete set of ports doesn't get reactivated. >>> It seems now that this was actually a bad idea. First of all, >>> `port' aborted in the middle, talking about not being able to >>> deactivate `libgcc8' (which is on the `macports.active' list). >> >> I'm not really sure, but one thing that might happen is that the >> list of ports to be deactivated comes in wrong order. If B depends >> on A and you call >> >>sudo port deactivate A B >> >> then I might fail to deactivate since port is processing them in the >> same order as they are written and complains that B depends on A, so >> A cannot be deactivated unless you force it or run it in a recursive >> way. > > Hmm. Shouldn't `port' handle such situations gracefully? It gets all > packages to be deactivated as a single call, it thus can reorder as > necessary. As far as I know, MacPorts does reorder the ports into the correct order. > Irrespective of the problems I wonder whether it is a valid approach > to deactivate everything – since `port' started with zero packages at > the very beginning, it should work, right? Yes, deactivating all ports should work successfully. We do that on the buildbot workers after every build. >> (Reading further, another reason could be that the ports you tried >> to deactivate cannot be deactivated as they are needed for the port >> command itself.) > > Ah, my fault, I was imprecise: `port' complained not being able to > deactivate `libgcc8' because it wasn't active. This implies that > `port' has implicitly already deactivated it and then stumbled over > the direct command to deactivate. I have seen this error with libgcc8 on the buildbot workers as well. I think we probably forgot a step back when the libgcc7/libgcc8 ports were introduced. For example, we may have forgotten to increase the revision of all the ports that depend on those ports. >> If you want to use a different libcurl, you could install that >> libcurl somewhere else. You can install two parallel macports (just >> make sure that you configure it properly to avoid clashes in >> /Applications/MacPorts, disable the services etc.) and then use one >> of them just as "supporting system" for the other one. We would >> have fixed this long ago if it wasn't for the chicken-and-egg issue >> :) > > Yes, this was explained to me on the list, but I was too lazy to go > that route. Now the issue knocked me down :-) IMHO, the best solution > would be to build a statically linked `port' program that is immune to > DLL problems – AFAIK, most GNU/Linux distributions do exactly that for > the central package manager (zypper, apt, rpm, etc.) Of course, macOS is not GNU/Linux and there are some differences. For example, whereas GNU/Linux uses its package manager to install everything, macOS comes with libraries like libcurl that are not managed by a package manager and we use them. There is no need to link with them statically, nor do we want to, for all the usual reasons: If that library is ever updated by Apple, we would not benefit from that update. The problem only arises when you do something unsupported, like linking MacPorts to libraries it itself installed. Please don't do that! :) I continue to believe that we should bundle a recent version of curl and libressl with MacPorts to avoid the too-old-openssl problem that we see on older macOS systems, but we have not reached consensus that we want to do that. See https://trac.macports.org/ticket/51516 >>> * Is there a simple way to protocol needed MacPorts packages? >> >> Needed by/for what? You can list recursive dependencies, inside the >> port you can run trace mode to make sure that no other files are >> used, listing active packages is possible (but note that you'll >> probably end up with build dependencies as well if you are building >> from source ...) > > I want to build `gub', the lilypond packager. Assuming that it works > I want to document how to build. Compiling all lilypond flavours from > scratch (including documentation) takes almost a day (using > approx. 20GByte of disk space), so it is quite important to know what > MacPorts packages must be installed before starting compilation for > obvious reasons. > > As an example, I can't
Re: problem with reactivating ports
Hello Mojca, thanks for replying! >> port echo active > macports.active >> sudo port deactivate `cat macports.active` >> >> to deactivate all MacPorts packages. I tried with the `-y' flag in >> advance, just to be sure... > > I understand the first command, but a much better way for the second > one would be > > sudo port deactivate active It's simpler, yes, but why is it `much better'? As far as I understand, later on I can't simply say sudo port activate inactive since the list of inactive ports is much larger due to updates. In other words, I have to store the list of active packages somewhere. >> It seems now that this was actually a bad idea. First of all, >> `port' aborted in the middle, talking about not being able to >> deactivate `libgcc8' (which is on the `macports.active' list). > > I'm not really sure, but one thing that might happen is that the > list of ports to be deactivated comes in wrong order. If B depends > on A and you call > > sudo port deactivate A B > > then I might fail to deactivate since port is processing them in the > same order as they are written and complains that B depends on A, so > A cannot be deactivated unless you force it or run it in a recursive > way. Hmm. Shouldn't `port' handle such situations gracefully? It gets all packages to be deactivated as a single call, it thus can reorder as necessary. Irrespective of the problems I wonder whether it is a valid approach to deactivate everything – since `port' started with zero packages at the very beginning, it should work, right? > (Reading further, another reason could be that the ports you tried > to deactivate cannot be deactivated as they are needed for the port > command itself.) Ah, my fault, I was imprecise: `port' complained not being able to deactivate `libgcc8' because it wasn't active. This implies that `port' has implicitly already deactivated it and then stumbled over the direct command to deactivate. >> Secondly, restarting `port' no longer works; [...] > > This is somewhat strange. This is my blind guess [...] Yes, this is it, I presume. Will work on that soon. > If you want to use a different libcurl, you could install that > libcurl somewhere else. You can install two parallel macports (just > make sure that you configure it properly to avoid clashes in > /Applications/MacPorts, disable the services etc.) and then use one > of them just as "supporting system" for the other one. We would > have fixed this long ago if it wasn't for the chicken-and-egg issue > :) Yes, this was explained to me on the list, but I was too lazy to go that route. Now the issue knocked me down :-) IMHO, the best solution would be to build a statically linked `port' program that is immune to DLL problems – AFAIK, most GNU/Linux distributions do exactly that for the central package manager (zypper, apt, rpm, etc.) >> * Is there a simple way to protocol needed MacPorts packages? > > Needed by/for what? You can list recursive dependencies, inside the > port you can run trace mode to make sure that no other files are > used, listing active packages is possible (but note that you'll > probably end up with build dependencies as well if you are building > from source ...) I want to build `gub', the lilypond packager. Assuming that it works I want to document how to build. Compiling all lilypond flavours from scratch (including documentation) takes almost a day (using approx. 20GByte of disk space), so it is quite important to know what MacPorts packages must be installed before starting compilation for obvious reasons. As an example, I can't directly start `gub' because Lion's python version is too old. I thus have to install `python' via MacPorts before I can explore what else is missing. Werner
Re: problem with reactivating ports
Dear Werner, On Sun, 13 Jan 2019 at 14:26, Werner LEMBERG wrote: > > I wanted to compile a project under MacPorts, and at the same time I > wanted to protocol what MacPorts packages must be installed in advance > before starting compilation. My glorious idea was to say > > port echo active > macports.active > sudo port deactivate `cat macports.active` > > to deactivate all MacPorts packages. I tried with the `-y' flag in > advance, just to be sure... I understand the first command, but a much better way for the second one would be sudo port deactivate active > It seems now that this was actually a bad idea. First of all, `port' > aborted in the middle, talking about not being able to deactivate > `libgcc8' (which is on the `macports.active' list). I'm not really sure, but one thing that might happen is that the list of ports to be deactivated comes in wrong order. If B depends on A and you call sudo port deactivate A B then I might fail to deactivate since port is processing them in the same order as they are written and complains that B depends on A, so A cannot be deactivated unless you force it or run it in a recursive way. (Reading further, another reason could be that the ports you tried to deactivate cannot be deactivated as they are needed for the port command itself.) > Secondly, > restarting `port' no longer works; it complains as follows > > dlopen(/opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib, 6): > Library not loaded: /opt/local/lib/libcurl.4.dylib > Referenced from: /opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib > Reason: Incompatible library version: > Pextlib.dylib requires version 10.0.0 or later, > but libcurl.4.dylib provides version 7.0.0 This is somewhat strange. This is my blind guess / speculation of what you did (I might be wrong). 10.7 became nearly hopeless with respect to fetching the sources (distfiles) after the servers started requiring a newer version of SSL protocol than what 10.7 can handle by default. So you probably recompiled MacPorts with something like --with-curl=/opt/local, but making a self-reference, and you ended up with a chicken-and-egg problem? > As a first aid I tried to re-install `port' from `macports-base', but > I still get this error. > > My questions. > > * How can I restore (i.e., re-activate) all installed MacPorts > packages? Given that I'm on Lion, I would *really* avoid > recompiling everything from scratch... If you want to avoid recompiling the ports themselves, it would probably make most sense to recompile macports (without --with-curl=/opt/local, or perhaps with another curl that's installed elsewhere) and run the port command again. If you want to use a different libcurl, you could install that libcurl somewhere else. You can install two parallel macports (just make sure that you configure it properly to avoid clashes in /Applications/MacPorts, disable the services etc.) and then use one of them just as "supporting system" for the other one. We would have fixed this long ago if it wasn't for the chicken-and-egg issue :) > * Is there a simple way to protocol needed MacPorts packages? Needed by/for what? You can list recursive dependencies, inside the port you can run trace mode to make sure that no other files are used, listing active packages is possible (but note that you'll probably end up with build dependencies as well if you are building from source ...) Mojca
problem with reactivating ports
[macports running from git] Folks, I wanted to compile a project under MacPorts, and at the same time I wanted to protocol what MacPorts packages must be installed in advance before starting compilation. My glorious idea was to say port echo active > macports.active sudo port deactivate `cat macports.active` to deactivate all MacPorts packages. I tried with the `-y' flag in advance, just to be sure... It seems now that this was actually a bad idea. First of all, `port' aborted in the middle, talking about not being able to deactivate `libgcc8' (which is on the `macports.active' list). Secondly, restarting `port' no longer works; it complains as follows dlopen(/opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib, 6): Library not loaded: /opt/local/lib/libcurl.4.dylib Referenced from: /opt/local/libexec/macports/lib/pextlib1.0/Pextlib.dylib Reason: Incompatible library version: Pextlib.dylib requires version 10.0.0 or later, but libcurl.4.dylib provides version 7.0.0 As a first aid I tried to re-install `port' from `macports-base', but I still get this error. My questions. * How can I restore (i.e., re-activate) all installed MacPorts packages? Given that I'm on Lion, I would *really* avoid recompiling everything from scratch... * Is there a simple way to protocol needed MacPorts packages? Werner
