[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libvir] Re: Fedora spec file changes



On Mon, Apr 28, 2008 at 12:23:09PM +0100, Mark McLoughlin wrote:
> Hey,
> 	First thing - libvirt.spec has previously matched the spec file we've
> used in Fedora for building packages, but now it's quite a bit out of
> sync.
> 
> 	My question is whether libvirt.spec should be upstream at all:
> 
>   1) Having the two copies is confusing - which is canonical?

  The one from upstream should be the canonical one of course.

>   2) Keeping the two copies in sync is time consuming, especially if 
>      they're not going to be exactly identical.

  i would love to keep them identical, but that's made harder by 
the idea in Fedora land that the specs are never part of upstream. 
up to one year ago, I was able to libxml2 and libxslt spec file completely
compatible between upstream and Fedora/RHEL. It *can* be done usually
and would be tons easier if that Fedora mentality that 'packaging details'
really don't need to be shared was abolished.
  Most of the time we need to fix something in the Fedora spec, this
means that to rebuild the same package on RHEL, CentOS, etc.. you need the
same kind of changes. Why this need to hide and bury this information
away from the upstream project ??? I really don't understand that viewpoint.

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

>   4) If we're to keep libvirt.spec in CVS purely as a convenience for
>      Fedora users wanting to build the latest tarball, then we should 
>      be ensuring that libvirt.spec is usable for the tarball *before* 
>      releasing it, which is a pain.

  it is *not* just Fedora users. I commonly rebuild on RHEL 5.x even RHEL4
libvirt.org is a RHEL4 for example and I had to build an RPM there to be able
install the environemtn to build libvirt-CIM checkout there.

> 	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.
  BTW if someone wants to put a .deb there or whatever the equivalent
may be for Debian i will take the patch.

Daniel

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]