Open ben-grande opened 2 weeks ago
The RPM requires each other, the problem arises when user just depends on another formula as a library, not to build everything (qubes) from the other project. On the other hand, sometimes they are necessary, such as sys-electrs
depending on sys-bitcoin
or dev
depending on sys-ssh-agent
and sys-pgp
. A notation to specify if another package is required to build the qubes needs to be created.
There are 55 RPMs specs, the build can take a long time. Maybe the number of RPMs will stay high, but what should be used instead is one RPM to provide the salt formulas as a library to be included by other formulas, instead of having to create all qubes of the other formula. qusal-lib
for example which would install all formulas states to /srv/
while qusal-dev
would only run the %install
stage basically, as there is nothing to be built.
Warning about qubes-release
: it is uncessary for separate repos, only useful if distributing all Qubes components.
Extraneous file: repodata/repomd.xml.metalink
, comps.xml
and comps-host.xml
. Metalink will only be useful once we have a mirror and comps only if we plan to mess with Fedora groups.
Technically, the Builder integration is "finished", what is unfinished is how to handle the RPM specs... should one RPM spec bring every formula as source and each separate formula only produces an installation procedure that depends on the source package? May be easier.
Current problem (if any)
Build is done on separate qube, but it is manual work.
Proposed solution
Builder V2 has nice properties such as building in a disposable qube that can have a chroot set to the same Fedora release, this can be good to avoid incompatibilities.
Builder V2 may be over powered considering all the code in Qusal was verified by me and there is no external dependencies.
The value to a user, and who that user might be
.