[Libvir] Fedora spec file changes
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? 2) Keeping the two copies in sync is time consuming, especially if they're not going to be exactly identical. 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? 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. Personally, I think we should remove it from upstream libvirt. Finally, here's some changes to how arch conditionals are handed in the spec file - what prompted this was the way we were enabling with_proxy even when with_xen was disabled, causing the proxy to be in the files section even when it wasn't built. Please give it a look over before I built in dist-f10. Cheers, Mark.
On Mon, 2008-04-28 at 12:23 +0100, Mark McLoughlin wrote:
Finally, here's some changes to how arch conditionals are handed in the spec file - what prompted this was the way we were enabling with_proxy even when with_xen was disabled, causing the proxy to be in the files section even when it wasn't built. Please give it a look over before I built in dist-f10.
Bah, see below. Cheers, Mark. Index: libvirt.spec =================================================================== RCS file: /cvs/pkgs/rpms/libvirt/devel/libvirt.spec,v retrieving revision 1.84 diff -u -p -r1.84 libvirt.spec --- libvirt.spec 28 Apr 2008 10:24:38 -0000 1.84 +++ libvirt.spec 28 Apr 2008 11:12:02 -0000 @@ -1,23 +1,30 @@ # -*- rpm-spec -*- -%if "%{fedora}" >= "8" -%define with_polkit 1 -%define with_lokkit 1 -%define with_proxy no -%else -%define with_polkit 0 -%define with_lokkit 0 -%define with_proxy yes +%define with_xen 1 +%define with_xen_proxy 1 +%define with_qemu 1 +%define with_polkit 0 +%define with_lokkit 0 + +# Xen is available only on i386 x86_64 ia64 +%ifnarch i386 i686 x86_64 ia64 +%define with_xen 0 +%endif + +%if ! %{with_xen} +%define with_xen_proxy 0 %endif %if "%{fedora}" %ifarch ppc64 %define with_qemu 0 -%else -%define with_qemu 1 %endif -%else -%define with_qemu 0 +%endif + +%if "%{fedora}" >= "8" +%define with_polkit 1 +%define with_lokkit 1 +%define with_xen_proxy 0 %endif Summary: Library providing a simple API virtualization @@ -51,12 +58,11 @@ Requires: /usr/sbin/lokkit %endif # For mount/umount in FS driver BuildRequires: util-linux -# PPC64 has no Xen nor QEmu, try to build anyway -%ifnarch ppc64 %if %{with_qemu} # From QEMU RPMs Requires: /usr/bin/qemu-img %else +%if %{with_xen} # From Xen RPMs Requires: /usr/sbin/qcow-create %endif @@ -67,7 +73,7 @@ Requires: lvm2 Requires: iscsi-initiator-utils # For disk driver Requires: parted -%ifarch i386 x86_64 ia64 +%if %{with_xen} BuildRequires: xen-devel %endif BuildRequires: libxml2-devel @@ -91,12 +97,11 @@ BuildRequires: /usr/sbin/lokkit %endif # For mount/umount in FS driver BuildRequires: util-linux -# PPC64 has no Xen nor QEmu, try to build anyway -%ifnarch ppc64 %if %{with_qemu} # From QEMU RPMs BuildRequires: /usr/bin/qemu-img %else +%if %{with_xen} # From Xen RPMs BuildRequires: /usr/sbin/qcow-create %endif @@ -121,7 +126,7 @@ Summary: Libraries, includes, etc. to co Group: Development/Libraries Requires: libvirt = %{version} Requires: pkgconfig -%ifarch i386 x86_64 ia64 +%if %{with_xen} Requires: xen-devel %endif Obsoletes: libvir-devel @@ -146,27 +151,19 @@ of recent versions of Linux (and other O %setup -q %build -# Xen is available only on i386 x86_64 ia64 -%ifarch i386 i686 x86_64 ia64 -%configure --with-init-script=redhat \ - --with-qemud-pid-file=%{_localstatedir}/run/libvirt_qemud.pid \ - --with-remote-file=%{_localstatedir}/run/libvirtd.pid \ - --with-xen-proxy=%{with_proxy} -%else -%ifnarch ppc64 -%configure --without-xen \ - --with-init-script=redhat \ - --with-qemud-pid-file=%{_localstatedir}/run/libvirt_qemud.pid \ - --with-remote-file=%{_localstatedir}/run/libvirtd.pid -%else -%configure --without-xen \ - --without-qemu \ - --with-init-script=redhat \ - --with-qemud-pid-file=%{_localstatedir}/run/libvirt_qemud.pid \ - --with-remote-file=%{_localstatedir}/run/libvirtd.pid +%if ! %{with_xen} +%define _without_xen --without-xen %endif + +%if ! %{with_qemu} +%define _without_qemu --without_qemu %endif +%configure %{?_without_xen} \ + %{?_without_qemu} \ + --with-init-script=redhat \ + --with-qemud-pid-file=%{_localstatedir}/run/libvirt_qemud.pid \ + --with-remote-file=%{_localstatedir}/run/libvirtd.pid make %install @@ -251,11 +248,9 @@ fi %{_datadir}/PolicyKit/policy/libvirtd.policy %endif %dir %attr(0700, root, root) %{_localstatedir}/log/libvirt/qemu/ -%ifarch i386 i686 x86_64 ia64 -%if %{with_proxy} == "yes" +%if %{with_xen_proxy} %attr(4755, root, root) %{_libexecdir}/libvirt_proxy %endif -%endif %attr(0755, root, root) %{_libexecdir}/libvirt_parthelper %attr(0755, root, root) %{_sbindir}/libvirtd %doc docs/*.rng
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/
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.
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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?
2) Keeping the two copies in sync is time consuming, especially if they're not going to be exactly identical.
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?
We also use in the nightly builds Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Apr 28, 2008 at 12:23:09PM +0100, Mark McLoughlin wrote:
Personally, I think we should remove it from upstream libvirt.
Definitely. Development & packaging are separate things. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
"Richard W.M. Jones" <rjones@redhat.com> wrote:
On Mon, Apr 28, 2008 at 12:23:09PM +0100, Mark McLoughlin wrote:
Personally, I think we should remove it from upstream libvirt.
Definitely. Development & packaging are separate things.
Doesn't it depend? I get the impression that *if* an upstream maintainer is willing to keep distro-specific spec files in the master repository, and to keep them in sync with the development sources, there's less lag and less chance that an upstream change would fail to percolate out to some distro's independently maintained spec files. The more "owners" there are of those spec files, the better maintained they will be.
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?
IMHO in isn't very useful. specfiles tend to be non-portable across distros. Usually works ok for small packages without special requirements. For more complex packages alot of little things add up. I've worked for SuSE for a while, so I have seen something which isn't Fedora, trust me ... Build dependencies are only one of many issues. Enabling/disabling services works differently across distros. Integration with distro-specific config tools isn't portable by definition. Also i386 libs on x86_64 are handled radically different by the build system if you compare Fedora and suse. KDE lives in /usr in Fedora, SuSE has it in /opt/kde3 (will change for kde4 though). Lots of little differences in packaging guidelines. Also note that %changelog is the *package* changelog which doesn't make sense at all in the upstream tarball. cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/
Perhaps the best thing is to link to this from the README file: http://cvs.fedoraproject.org/viewcvs/devel/libvirt/libvirt.spec?view=markup Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
On Mon, Apr 28, 2008 at 03:11:20PM +0200, Gerd Hoffmann wrote:
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?
IMHO in isn't very useful. specfiles tend to be non-portable across distros. Usually works ok for small packages without special requirements. For more complex packages alot of little things add up. I've worked for SuSE for a while, so I have seen something which isn't Fedora, trust me ...
Build dependencies are only one of many issues. Enabling/disabling services works differently across distros. Integration with distro-specific config tools isn't portable by definition. Also i386 libs on x86_64 are handled radically different by the build system if you compare Fedora and suse. KDE lives in /usr in Fedora, SuSE has it in /opt/kde3 (will change for kde4 though). Lots of little differences in packaging guidelines.
Also note that %changelog is the *package* changelog which doesn't make sense at all in the upstream tarball.
There are differences. The point is to share the data (and it should be reasonable to be able to maintain the spec file allowing to rebuild on RHELs, on Fedoras, on CentOSes at least). Having the information makes it easier for the developpers (for the point I explained, libvirt embedding a system daemon, packaing influence the ability to test easilly and develop), and even if there are divergences it's better to start from something than from scratch. Being able to diff the spec file between version N and M should also help the distro packager to see how he should update his local version. I really don't understand why people think that only the least common denominator should be shared instead of sharing the maximum information possible. The SuSE or the Mandriva packager will find easier to look for spec file or change in the tarballs than digging fedora or RHEL pakages I think. Why would having a spec file in the tarball be a nuisance for others, it really isn't. I have done that for 10 years, I don't think I ever got a complain about that from a packager. Strangely the Fedora people seems to be the one not understanding how useful this can be... And as rpmfind.net maintainer, I have seen my load of poor users requests trying to get or build a version of software which didn't come prepackaged for their setup. I will take Debian, Solaris, OSX, VMS, MVS, Windows, ... build patches and instructions any day based on the simple premice that sharing informations which may be useful to the end user is what is useful in the end. The informations may be outdated at time it may be missing something, but it's an important amount of knowledge about the project which need to be persisted and shared. Ultimately users noticing a problem will report it back where it belongs, i.e. upstream for everybody's benefit, that's how we should work here. 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/
participants (6)
-
Daniel P. Berrange -
Daniel Veillard -
Gerd Hoffmann -
Jim Meyering -
Mark McLoughlin -
Richard W.M. Jones