Hi,
After discussion with a MacPorts "newby" who was motivated to use my ports tree
(to get at the KF5 ports), I clarified the instructions in my README:
{{{
Ports that are in my repository but are also in the default repository will
override those in the default repository (and all other repositories listed
after site-ports in sources.conf). If you use the aforementioned [nosync]
option, you'll have to update the tree yourself. In that case you may have to
do `portindex -f` at least periodically, to account for changes like removed
variants or subports.
An important note: this repository also contains PortGroup files. These files
that contain definitions that are used by multiple ports that share certain
properties (form a group, say all ports that build using CMake, or that use Qt
or KDE libraries). PortGroups are like C header files, or Python/Perl/Tcl
packages, included via a specific command in a port's "Portfile". Note that
PortGroups themselves can include other PortGroups in exactly the same way! An
example: the command `PortGroup kf5 1.1` will include the file kf5-1.1.tcl,
which will then include other PortGroup files like qt5-1.0.tcl, qt5-kde-1.0.tcl
and cmake-1.0.tcl. Each file will be included from either the same _resources
directory, or else from the default _resources directory.
These PortGroups apply only to the ports in the local repository. This may lead
to surprising behaviour and errors. For instance, if you install my
port:qt5-kde or port:qt5-kde-devel, every port (including those in the official
port tree) that requires Qt5 will need to use the corresponding Qt5 PortGroup
(the qt5-*1.0.tcl files and probably qmake5-1.0.tcl), esp. if you plan to build
them from source.
You will thus have to copy the corresponding files from the
/opt/local/site-ports/_resources directory to the same directory in the default
port tree (defined in sources.conf). You will have to do this again after each
selfupdate.
Sadly there isn't much that can be done at the moment to make this more
convenient. The best rule of thumb is to check for each port you install from
my tree what PortGroups it uses (fgrep PortGroup `port file foo`), identify the
corresponding files and files those include, check which ones are present in
site-ports/_resources, and copy those files to the default _resources directory.
}}}
I thought it might be useful to cite that text here.
It also made me wonder if we couldn't come up with an alternative to changing
the lookup strategy in "base". As mentioned, there is currently no assistance
whatsoever to determine what PortGroups might have to be copied, and of course
the source and destination directories aren't exactly trivial to find either.
That makes the task a bit daunting for people unfamiliar with MacPorts and esp.
if they're not experienced terminal users.
How about a mechanism akin to `port select`, in which a port can declare which
PortGroup files it uses and needs to be made available outside the local port
tree. That information can be defined in the Portfile (as an installable file)
or else in a separate file in the port dir, and could be used via a specific
command (e.g. provided by a port with convenience utilities for using custom
port trees). An initial implementation could simply take care of copying the
required PortGroups (and register a reminder to be printed after each
selfupdate). A slicker implementation would maintain a lookup table for the
concerned PortGroups, meaning only those are handled differently and all others
keep following the current lookup strategy.
Then again all this seems overkill to me. I really cannot come up with a valid
scenario in which you'd want a PortGroup to be confined to its local tree. If a
local (custom) port needs to override a global PortGroup for some reason it can
simply use one that has a different name or version (one not used by any global
port; I presume the version is simply a string and doesn't have to be numeric
so one could do something like `PortGroup qt5 private`).
Am I missing something that should be evident?
R.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
