6:23 a.m.
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.
6:24 a.m.
New subject: [Libvir] Re: Fedora spec file changes
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
6:57 a.m.
New subject: [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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
8:36 a.m.
New subject: [Libvir] Re: Fedora spec file changes
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.
8:56 a.m.
New subject: [Libvir] Re: Fedora spec file changes
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
7:09 a.m.
New subject: [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?
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 :|
7:42 a.m.
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
7:55 a.m.
"Richard W.M. Jones" <rjones(a)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.
8:11 a.m.
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/
8:22 a.m.
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
8:33 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6054
days inactive
6054
days old
10 comments
6 participants
participants (6)
-
Daniel P. Berrange -
Daniel Veillard -
Gerd Hoffmann -
Jim Meyering -
Mark McLoughlin -
Richard W.M. Jones