[Libvir] Re: Fedora spec file changes

[Daniel Veillard]

On Mon, Apr 28, 2008 at 02:36:48PM +0100, Mark McLoughlin wrote:
> 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.

  Except for that sentence. You can't impose that on the packager in the
distro. But it's normal behaviour to send back patches, which may or
may not fit directly, just that reporting upstream should be the 'normal'
behaviour, that does not mean you need agreement before applying any 
packaging patch, really!
  Like if you find an compilation error due to a new version of gcc, i would
expect the local patch to be sent upstream, even if in the end the project
may do the change in a slightly different manner.

>    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.

  You're blocking on a self imposed rule IMHO...
And yes i would prefer the change to the spec file to still allow to build
on RHEL/CentOS, as this is a rather frequent operation.

> >   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.

  I do that very often ! Maybe the old man is a bit slow, or stupid, but
heh, that works.

> 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.

  But libvirtd relies more and more on /etc/ files and interaction with
other system elements, if you don't do a 'make install' you're really
testing something that nobody will ever run.

> >   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"
> 
>   ...

  you misunderstood what I wanted to express, I was speaking about 
the spec file and the rules applying to them, not to the distro 
Things like awk not being considered a prerequisite at build time
forcing to add BuildRequires awk or similar 

> 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.

  Completely generic spec files attempts failed I agree it's difficult,
but the 'of little practical benefit' is something I challenge. If we
could do 'configure ; make package' like we do 'configure ; make install'
I'm sure you would find it of great benefit.

  That doesn't work all the time, but when it does *I* find it great.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/