Opened 2 years ago
Last modified 2 years ago
#66485 new enhancement
While I am installing port 1 I cannot build port 2
Reported by: | ballapete (Peter "Pete" Dyballa) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.8.0 |
Keywords: | Cc: | ||
Port: |
Description
Modern Macs have more than one CPU core so that it is possible to perform a few things in parallel. But port is very old fashioned and prevents building and installing one software and just building another one that is not depending on the software that is being built to become installed. Why? What is the sense? I do understand that it can be hard to record in a DB when two installation run at the same time, but here just one build step for a future installation is going on and I want to save some time by performing another build. Nothing to be tracked, or?
tiger:~ root# nice port rdeps diffutils The following ports are dependencies of diffutils @3.8_0: xz lbzip2 apple-gcc42 ld64 ld64-97 libmacho-headers libunwind-headers cctools gcc_select legacy-support gettext libiconv gperf libtextstyle ncurses gettext-runtime gettext-tools-libs
Curl is being being built for installation…
Change History (8)
comment:1 Changed 2 years ago by jmroot (Joshua Root)
comment:2 Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
But I am not:
sudo port -vds build diffutils Password: DEBUG: Changing to port directory: /opt/local/var/macports/sources/nue.de.rsync.macports.org/macports/release/tarballs/ports/sysutils/diffutils DEBUG: OS darwin/8.11.0 (macOS 10.4.11) arch powerpc DEBUG: Sourcing PortGroup compiler_blacklist_versions 1.0 from /opt/local/var/macports/sources/nue.de.rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl DEBUG: compiler clang blacklisted because it's not installed or it doesn't work DEBUG: adding the default universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/nue.de.rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Chosen compiler apple-gcc-4.2 is provided by a port, adding dependency DEBUG: Adding depends_build port:apple-gcc42 DEBUG: Adding depends_skip_archcheck apple-gcc42 DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: Attempting ln -sf /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_sysutils_diffutils/diffutils/work /opt/local/var/macports/sources/nue.de.rsync.macports.org/macports/release/tarballs/ports/sysutils/diffutils/work DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: Starting logging for diffutils @3.8_0 DEBUG: Mac OS X 10.4.11 (darwin/8.11.0) arch powerpc DEBUG: MacPorts 2.8.0 DEBUG: Xcode 2.5, CLT none DEBUG: SDK 10.4 DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.4 Waiting for lock on /opt/local/var/macports/registry/.registry.lock
In one instance of GNU Emacs pango
is being built in some variant for installation
, in another instance of GNU Emacs I wanted to build again diffutils
. There are no obvious remote dependencies, because then second port
would try to build pango
which is not installed right now.
comment:3 Changed 2 years ago by jmroot (Joshua Root)
The diffutils port has a number of dependencies. Checking whether they are installed, installing them, and doing the build that uses them have to be done with the lock held, otherwise another port process could install or uninstall any of those dependencies after they are checked for, resulting in incorrect behaviour.
If you want to be responsible for making sure this doesn't happen, you could edit ${prefix}/libexec/macports/lib/registry2.0/registry.tcl
and edit the exclusive_lock
and exclusive_unlock
procs to do nothing. But if it breaks, you get to keep the pieces.
comment:4 Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
port
lists a handful of dependencies that are all met. Otherwise it would try to install a missing dependency and would have to wait until it has the right to perform so. port
lists 17 rdeps, all of them are them are met. Cairo is none of them, and so it Panga. So why does port fail?
comment:5 Changed 2 years ago by jmroot (Joshua Root)
You can deduce that it is safe to run these particular commands at the same time because you have the benefit of knowing what actions you are performing, the ports they are operating on, what their dependencies are, and the current state of those dependencies. Each port
process on the other hand has no way of knowing what the others are going to do.
comment:6 Changed 2 years ago by ballapete (Peter "Pete" Dyballa)
Hoe can software components vanish by installation? The act removing is called de- or uninstallation. Even when I change software +variant_a to software minus or plus any other variant nothing will vanish, because each variant is equivalent (otherwise it would be a different port).
comment:7 Changed 2 years ago by jmroot (Joshua Root)
Again, you know that nothing is being uninstalled by the particular commands you run, but port does not. You could just as easily run port install pango
and then port uninstall ninja
while the first command is still running.
Of course these problems are not impossible to solve, but I hope you understand that the lock is not there just to get in your way, and that implementing a finer-grained locking scheme would be a significant amount of work.
comment:8 Changed 2 years ago by ryandesign (Ryan Carsten Schmidt)
On macOS 10.15, I very often have multiple terminal windows open performing separate sets of builds at the same time, so it is already possible to do so, in some circumstances. (I'm not sure what the conditions are that lead to the "Waiting for lock" message you encountered.)
You should be able to build, what you can't do is any operation that may need to install something else, including things like extract dependencies. Any operation involving the registry would be subject to TOCTOU errors if the lock were not in place.