Date: Wed, 25 Oct 2023 14:11:11 +0900 From: Tatsuki Makino <tatsuki_makino@hotmail.com> To: ports@freebsd.org Subject: Re: We need to do something about build times Message-ID: <SI2PR01MB5036CDD2BAE2A610C3A96554FADEA@SI2PR01MB5036.apcprd01.prod.exchangelabs.com> In-Reply-To: <ZTgXDSmpAq6lpT3f@fuz.su> References: <ZTgXDSmpAq6lpT3f@fuz.su>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello. In the machine where those packages are installed, there's no need to update ports that don't show up in the result of pkg version. However, since the version number is also recorded in the dependencies in the package, everything is rebuilt just to rewrite it. For example, information displayed by pkg query -F llvm15-15.0.7_7.pkg %dn-%dv. Some time can be saved by manually running a dry run of poudriere and examining it for the above reasons. However, contamination occurs, which reduces the reliability that the packages is normal :) But can someone create a tool that can automate such a workaround? I have created a tool that could be a clue to that :) It is left somewhere in freebsd-ports@ or ports@ :) Below is a list of packages that take a long time to build and workarounds. gcc12: It is removed when binutils is updated or otherwise. If +*MANIFEST is rewritten only when the binutils version changes, there is little need to rebuild. llvm1?: Deleted when python is updated. When python is updated, simply rewrite +*MANIFEST to eliminate the need to rebuild. webkit2-gtk?: It will be removed as part of the upstream update of gtk. Manually rebuilding gtk would help. qt5-webkit: In most cases, it is caught up in the upstream update of gt5-gui and removed. Manually rebuilding qt5-gui would help. py-qt5-pyqt: It can usually be helped by manually rebuilding upstream. doxygen: I want some patch in bug 259331 :) In most cases, it is just caught up in the fact that graphbiz has been deleted, so just rebuild graphbiz. texlive-texmf: It is involved in texlive-base being removed and deleted. When this is removed, the high volume of access to the file takes up a lot of time. Or rather, I suspect that a bug was introduced in the middle of stable/12 that made it vulnerable to multiple simultaneous accesses of files :) There are many reasons why texlive-base may be removed. ghostscript, poppler, what else was there? :) When nss is updated, for some reason poppler is also deleted (reason unknown). ffmpeg: This has been used in so many places that it would be very difficult to have it removed. However, aom and vulkan are frequently updated and removed, so if they are candidates for a dry run, this should also be manually rebuilt. gstreamer1-*: Sometimes it is better to rebuild this area manually, as it will have a negative impact downstream. glib20: If we don't make mistakes in the procedure, there is surprisingly little to rebuild. If you make a mistake in the procedure, texlive will be deleted :) rust: If the curl is just caught up in the deletion of the curl, then simply rebuilding the curl is all that is needed. If the curl is updated, it can be solved by rewriting the +*MANIFEST. If rust itself is updated, we will have no choice but to watch Net*lix. When there is an update of something like gettext, there is no way to get around it :) Anyway, poudriere is just looking there :) https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/include/pkg.sh#L128 Regards.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SI2PR01MB5036CDD2BAE2A610C3A96554FADEA>