Chavdar Ivanov <ci4ic4%gmail.com@localhost> writes: > The point is, bulk builds may fail in different places, e.g. my > example regarding asciidoc above. If you get a fresh version of pkgsrc > you won't be able to build asciidoc today, if you have at some stage > enabled the pdf option, which is not a default one. Whether this is > important is another matter. I guess, in this case the solution would > be to remove the pdf option from asciidoc completely, until somebody > ports dblatex to python3. It's not a big deal, just one of the quirks > one deals when using pkgsrc. I don't see what this has to do with difficulties doing incremental updates. It is true that pkg_rr, make update, and pkgin all do things less well than a human could suggest when packages get removed, renamed, have files moved into libraries that they then depdn on, have this old-package-for-py27 scheme, and various other things. pkgsrc considers itself correct if a bulk build from nothing succeeds. And, each package has to build correctly even if an older version is installed. Further, it's nice not to do things that break in-place updating and hence we discourgae renaming unless it's really necessary and/or worth the pain imposed on users. Usually every quarter there are a few things that need manual attention from people doing pkg_rr/make-update/pkgin. This just seems to be one of them. Are you saying that building asciidoc with the pdf option now fails? I just did make PKG_OPTIONS.asciidoc=pdf package in textproc/asciidoc and it finished just fine. Yes, asciidoc depends on python37 and dblatex on python27, but I don't see a problem with that.
Description: PGP signature