On Thu, 2020-04-02 at 10:26 +0100, Daniel P. Berrangé wrote: > On Thu, Apr 02, 2020 at 11:24:25AM +0200, Andrea Bolognani wrote: > > On Thu, 2020-04-02 at 09:41 +0100, Daniel P. Berrangé wrote: > > > Please ignore all the RPMs you see there, they really shouldn't be > > > used. > > > > Can we just stop generating them? > > > > And get rid of all the existing ones, especially silly stuff like > > the binary RPMs from 2013 targeting Fedora 17. This will have the > > additional benefit of making it easier to find what you're looking > > for, since it will no longer be hidden among a heap of irrelevant > > garbage. > > Yes, I mentioned in the doc about adopting gitlab for infra, that > we should stop providing the RPMs. Right. Can we start not creating the RPMs with 6.2.0? I've added DV to the thread. Can someone with the appropriate permissions remove all existing RPMs from libvirt.org/sources? Even after it becomes a mirror rather than the primary download location, we still don't want it to be cluttered with obsolete content. > > > The source tarballs (eg libvirt-5.9.0.tar.xz) contain a spec file > > > inside. > > > > > > This means you can generate RPMs for your precise distro using something > > > akin to the following commands: > > > > > > $ rpmbuild -ts libvirt-5.9.0.tar.xz > > > $ sudo dnf install redhat-rpm-config > > > $ sudo dnf builddep $HOME/rpmbuild/SRPMS/libvirt-5.9.0-1.fc31.src.rpm > > > $ rpmbuild --rebuild $HOME/rpmbuild/SRPMS/libvirt-5.9.0-1.fc31.src.rpm > > > > I think it would make sense to document this quick procedure > > somewhere, if we haven't already. There's some obvious overlap with > > our 'make rpm' target, but that one requires unpacking the release > > archive and running configure beforehand, so it's not quite as nice > > for someone who just wants to quickly get a working set of RPMs. > > The README.md and the https://libvirt.org/compiling.html pages are > good candidates. Can you try coming up with a patch? I would do that myself, but you're obviously way more experienced when it comes to RPM packaging. I pledge to test and review your documentation in a reasonably timely manner in exchange :) -- Andrea Bolognani / Red Hat / Virtualization
