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/