poudriere
poudriere copied to clipboard
Thin repositories
it does not depends actuallt on #797 but I am too lazy to split that in to so will go in after #797 :D
I like this but wonder what the use case is and what it buys us? Is this so a user can provide just like 1 custom package and use FreeBSD repo otherwise?
bapt was mentioning its equivalency to a PPA repo, but the thin repos could also immediately solve some issues without some of the problems described later in your message. e.g., the drm kmod packages have no irrelevant runtime dependencies that could cause those kinds of problems, so we could build them in a thin repo on and for 12.2 users without much hassle.
The medium repos address your concerns in the sense that they encapsulate all of the dependencies that could cause issues at runtime, and they solve brooks' problem that they just want to build and publish exactly what they want + run/lib depends for those to minimize the I/O work that pkg needs to do on some of their slower (emulators?) when searching the database or whatnot.
As for the usage all what @kevans91 said, about could we make it a hook, yes we could, but imho there will be too many users of those feature that it deserves a proper support. Think all maintainers could provide their own packages more easily. kde-devel repo, libreoffice-devel repo etc.
Our (CHERI) use case is very slow emulators (on par with FGPA implementations in the 10-50MHz range) with awful disk I/O. Reading a trivial pkg database can take minutes in some cases (I did an install of a clang/llvm/lld pkg and it took a couple hours). We've got access to some full-SoC FPGA emulations that are going to be even worse (though we probably won't be installing packages on them).
The release of 12.3 is coming up in about a month. I think this feature was envisioned as the solution to the incompatibility between kmod's built on 12.2, and people running 12.3.
Is there a plan to finish this work?
Stumbled upon this from https://github.com/freebsd/poudriere/issues/1025. This would be perfect fit for -b <URL>
. When I compare the packages from <URL>
and the fetched packages, they are duplicated rather than dropping them after the build or not adding to the final repo. As for PPA: here is another example: http://opensource.wandisco.com/rhel/8/svn-1.14/RPMS/x86_64/
Contains only required runtime packages, rest is pulled from default repo which makes sense.
So I am highly in favor of this.
This, unfortunately, didn't make it into 3.4.0 :-(