On 2025/02/11 22:00, Stuart Henderson wrote: > On 2025/02/11 21:25, Rafael Sadowski wrote: > > On Tue Feb 11, 2025 at 08:01:46PM +0100, Ingo Schwarze wrote: > > > Hello Rafael, > > > > > > Rafael Sadowski wrote on Tue, Feb 11, 2025 at 02:23:31PM +0100: > > > > > > > When I look at FreeBSD they have subpackages for -docs -man and -gui. > > > > I like it! > > > > > > I do not want to comment on cmake, but in general, manual pages ought to > > > be in the same package as the program they document, so a separate -man > > > package is almost always wrong. When "$ foo" works, then "$ man foo" > > > ought to work, too, without any further pkg_add(1). > > > > > > > I'm with you! > > > > It's only for the distributed ports build system. We can install > > cmake-man as run-dependency can't we? > > There would be no benefit in splitting out the manuals if the package > containing binaries had the manuals as a run dependency. (The main > problem is the chain of dependencies to build sphinx, including > python, numpy, lapack, and a bunch of others). > > It _could_ be handled with a split like this: > > pkgpath pkgname contents > devel/cmake/core cmake-core binaries, required cmake modules, etc > devel/cmake/man cmake-man manuals > devel/cmake/cmake cmake depends on cmake-core + cmake-man > > With this, a typical user installing cmake would "pkg_add cmake" > and get everything, whereas somebody just pulling it in as a ports > build dependency would get devel/cmake/core. > > Whether that's considered acceptable, I don't know. Personally I don't > think it's ideal, but it's not too awful, and avoiding sphinx as a build > dependency of the cmake binaries is very appealing (so far, we've been > able to break dependency loops, but the way Python packaging goes, I'm > not confident in that continuing forever..) > > The diff for that would look like the one below. (As an added bonus > it also makes it easier to grep for ports using cmake without the > module)
Any comments on this approach? Apart from reducing risk of build loops if things change around py-sphinx, it will mean that ports using cmake can start much earlier in a bulk build. > ...what I'd consider best overall for packagers would be if upstream > would include generated manpages in their distribution, but that means > there would be a difference between a "release" build and a build from > the source tree, which they might not like, and I suspect they don't > treat manpages as the most important part of their documentation... <snip complete diff>, here's just the diffstat instead, fetch it from https://marc.info/?l=openbsd-ports&m=173931122727645&q=mbox if you want it (it may have rotten by now - the diff for most ports is just s,devel/cmake,devel/cmake/core,) audio/ncspot/Makefile | 2 audio/spotify-player/Makefile | 2 cad/horizon-eda/Makefile | 2 comms/gammu/Makefile | 2 databases/recoll/Makefile | 2 devel/cmake/Makefile | 97 - devel/cmake/Makefile.inc | 46 devel/cmake/cmake.port.mk | 2 devel/cmake/cmake/Makefile | 17 devel/cmake/cmake/pkg/DESCR | 10 devel/cmake/cmake/pkg/PLIST | 1 devel/cmake/core/Makefile | 53 devel/cmake/core/pkg/DESCR-help | 1 devel/cmake/core/pkg/DESCR-main | 1 devel/cmake/core/pkg/PLIST-help | 2158 ++++++++++++++++++++++++++++++++++++++++ devel/cmake/core/pkg/PLIST-main | 1664 ++++++++++++++++++++++++++++++ devel/cmake/man/Makefile | 11 devel/cmake/man/pkg/DESCR | 1 devel/cmake/man/pkg/PLIST | 27 devel/keystone/python/Makefile | 2 devel/py-lief/Makefile | 2 devel/py-unicorn/Makefile | 2 games/0ad/base/Makefile | 2 geo/py-osmium/Makefile | 2 lang/deno/Makefile | 2 lang/mono/Makefile | 2 lang/rust/Makefile | 2 math/py-osqp/Makefile | 2 net/bro/Makefile | 2 net/unifi/snappy-java/Makefile | 2 textproc/hotdoc/Makefile | 2 wayland/wayfire/Makefile | 2 wayland/wf-config/Makefile | 4 33 files changed, 4016 insertions(+), 113 deletions(-)
