Hi,
Okay, reading between the lines of your mail, I think the policy on
libvirt.spec in libvirt CVS is something like:
"This spec file is intended to be the canonical source spec file for
building libvirt RPMs on Fedora 3+, RHEL 4+ and equivalent variants.
On any of these distributions, you should be able to build a libvirt
release using the command:
$> rpmbuild -ta libvirt-$(version).tar.gz
If you are a Fedora or RHEL packager, please ensure any changes you
make are reviewed and accepted in upstream libvirt.
The obvious exception to this is the "release" field and the
changelog section - these clearly may differ between different
distro versions.
Any spec file change you do upstream, please try and include a
changelog entry for that change and endeavour to ensure it builds on
the distro versions listed above.
"
>From my POV, that's just about doable - I could attempt to follow those
guidelines.
That's still quite a bit of work and confusion for the benefit of a very
narrow group of people, IMHO.
Also, I think it makes libvirt's Fedora packaging significantly more
difficult to contribute to than other Fedora packages.
On Mon, 2008-04-28 at 07:57 -0400, Daniel Veillard wrote:
> On Mon, Apr 28, 2008 at 12:23:09PM +0100, Mark McLoughlin wrote:
> > 3) It's not clear that it's useful to have it upstream at all - i.e.
> > is it useful anywhere but Fedora? Are iscsi-initiator-utils or
> > selinux-devel valid RPM names on any other distro?
>
> as if there was one Fedora. there is a number of them, there is a number
> of RHEL, and all the associated derivatives.
> I do 'make rpm' on at least 3 different platforms of that type. And with
> libvirt being highly dependant on the libvirtd daemon, it's not something
> you can just test from a compiled checkout tree. You need to install and
> restart the service. Installing a service in /usr and /etc without using
> an RPM on an RPM based system is just insane.
You make a valid point about the difficulty of working on libvirtd.
I don't think building an RPM to test changes to libvirtd is really a
usable method for developers, though. That's not a nice test/debug
cycle.
Also, note that the spec file only helps libvirtd developers on a subset
of the platforms that they might be working on.
I don't know about other people who have worked on libvirtd but I took
the approach of running libvirtd from a CVS checkout as much as
possible.
Docs or helper scripts would help this much better than a spec file,
IMHO.
> > Personally, I think we should remove it from upstream libvirt.
>
> and I think this Fedora viewpoint 'spec is useful only for assembling
> a distro and we own that' to be myopic, sorry.
Your assumption that the Fedora viewpoint on this is a proprietary or
secretive one is fairly uncharitable, really.
You've seen from up-close:
1) The merging of Core and Extras
2) The opening up of Core development
3) The external build system, version control etc.
4) The Fedora mantra of "get everything upstream"
...
If you took Fedora packagers' intentions in good faith, you might just
have thought that Fedora packagers have concluded, from experience, that
trying to maintain upstream, generic spec files is extremely difficult
and of little practical benefit.
Cheers,
Mark.
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list