Opened 17 months ago

Last modified 17 months 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 17 months ago by jmroot (Joshua Root)

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.

comment:2 Changed 17 months 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 17 months 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 17 months 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 17 months 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 17 months 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 17 months 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 17 months 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.)

Note: See TracTickets for help on using tickets.