[Libvir] Fedora spec file changes

Daniel Veillard veillard at redhat.com
Mon Apr 28 13:33:46 UTC 2008

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


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/

More information about the libvir-list mailing list