Subpackages is a feature focused on packages.
However, port builders lack the ability to install portion of a port,
causing a very different behavior.
With this patch we add the ability to install only subpackages
specificed by the TARGET_SUBPACKAGES variable.
This variable is going to contain a comma separated list of subpackages.
If the variable is missing, all subpackages are installed
The variable works for install and reinstall targets.
The deinstall targets keep the previous behavior, removing the whole port.
Details
- Reviewers
- None
- Group Reviewers
portmgr
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 55861 Build 52750: arc lint + arc unit
Event Timeline
This is the "install" part only. Is this review also supposed to get the dependency part for this to work (e.g. a port depending on only a subpackage and the recursive dependency tracking and install needs to set TARGET_SUBPACKAGE), or is the dependency part supposed to come / available in another review?
Mk/bsd.port.mk | ||
---|---|---|
4866 |
|
Mk/bsd.port.mk | ||
---|---|---|
4878 | I'm not quite sure why _DEPPKGS is needed at all. To ensure the order in which subpackages are installed in case of interdependencies? |
- Use a comma separated list of subpkg
- Add documentation for TARGET_SUBPACKAGES variable
Mk/bsd.port.mk | ||
---|---|---|
4878 | There is a target per subpackage. Subpackages can have other subpackages as dependencies. |
Mk/bsd.port.mk | ||
---|---|---|
4866 | Good points. |
Running make -C audio/alsa-plugins/ -V _IPKGS TARGET_SUBPACKAGES=, results in emptiness. Not sure if this is a bug, though, but probably should be fixed for POLA sake.
If some subpackages have been disabled via options, should we force to build them anyway if they are listed in TARGET_SUBPACKAGES? What if other ports rely on particular subpackage?