Structure of the RPM repositories

r1

@stormi said in Structure of the RPM repositories:

community_testing is for those community-provided RPMs while still at an experimental state. Disabled by default, of course.

Im no expert of this but looks ok and usable to me except I feel community and community_testing are same because both are going to be supported by community only and pretty much always be in an experimental stage.

Another suggestion, instead of community, you may want to mention "experimental" as it warns user. The project itself is a community-driven project and may not need another subdirectory showing "community" as some external set of members.

My 2c.

stormi

@r1 said in Structure of the RPM repositories:

Im no expert of this but looks ok and usable to me except I feel community and community_testing are same because both are going to be supported by community only and pretty much always be in an experimental stage.

This may be true. I considered that community would mean "unsupported, but people used it with success" whereas community_testing would mean "untested, except by me". If you've got some driver RPM already in use by several in community and want to test a risky change, having community_testing available for that could be useful.

But we could also start without and add it later if need be.

Another suggestion, instead of community, you may want to mention "experimental" as it warns user. The project itself is a community-driven project and may not need another subdirectory showing "community" as some external set of members.

You're right. I thought of it and changed the name several times while writing the document but I finally came back to community, though it's probably not the best choice. My concern with "experimental" was that there would probably be some officially unsupported packages in it that would actually get good support from those who provide them. On the plus side, its name conveys an unambiguous meaning of "unsupported". On the minus side, it's hard to understand the difference between experimental and updates_testing without an explanation I think.

Other options:

extras
lab
anything else?

r1

extras is fine by me. A readme file in that directory with sufficient warning to make user alert but not scare away & a file with list of package => user xcp-ng profile link will help.

stormi

Let call it extras then. Ok for the readme and credits files.

stormi

New repository structure is online, without any stable branch yet (since 7.4.1 used a different structure).

https://updates.xcp-ng.org/7/dev/

Not usable yet for testing, but I invite you to start using it for RPM building and to report issues.

[xcp-ng-main]
name=Main repository for XCP-ng
baseurl=https://updates.xcp-ng.org/7/dev/main/x86_64/
gpgcheck=0
priority=1

[xcp-ng-builddeps]
name=Build dependencies for XCP-ng
baseurl=https://updates.xcp-ng.org/7/dev/builddeps/x86_64/
gpgcheck=0
priority=2

Note that if you install the yum-plugin-priorities package, you'll probably meet some errors when trying to install -devel packages from CentOS repositories. But that's a good thing in my opinion because that encourages us to rebuild the source RPMs corresponding to the exact version of packages in xcp-ng-main, to avoid build errors related to API changes (such as that of libdrm that breaks the build of qemu-dp).

And if someone very brave manages to make an ordered list of all the source RPMs by build order, in order to be able to rebuild them all without CentOS repositories at all, I promise to rebuild them and push them to the builddeps repo!
Actually, I think we might have to import some source RPMs from CentOS to boostrap the process, but afterwards we would have a solid build environment for 7.5

r1

@stormi said in Structure of the RPM repositories:

And if someone very brave manages to make an ordered list of all the source RPMs by build order, in order to be able to rebuild them all without CentOS repositories at all, I promise to rebuild them and push them to the builddeps repo!

Only Citrix knows it, see if you can get this order from @johnelse.

stormi

We can infer most of it from the BuildRequires of the source RPMs actually.

r1

I tried it once but it gave me cyclic dependencies. Im new to the process. YMMV.

stormi

Yes, you usually need a phase called "bootstrapping" in the distros world where you start with some prebuilt binaries of A in order to be able to build B which will in turn be used to rebuild A

stormi

Updated: main renamed to base.