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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list