Title: Re: FW: [Oscar-checkins] r3315 - in trunk/packages/sis: SRPMS distro/fc2-i386 distro/fc3-i386 distro/mdk10-i386
Along with those lines it'd be useful to modify our system for building the release tarballs, or create a script which creates a tarball of _only_ the files needed for a particular distribution.  Our tarball is now almost getting close to 300MB so it would be handy to be able to create a tarball for files necessary for only Fedora Core 3, for instance - I have no need to have files from RHEL4 unless I plan to have a hetereogenous cluster (a functionality we don't currently support anyways).
 
What do you guys think?
 
Cheers,
 
Bernard


From: Erich Focht [mailto:[EMAIL PROTECTED]
Sent: Sun 17/07/2005 1:53 PM
To: Bernard Li
Cc: [email protected]
Subject: Re: FW: [Oscar-checkins] r3315 - in trunk/packages/sis: SRPMS distro/fc2-i386 distro/fc3-i386 distro/mdk10-i386

Hi Bernard,

On Sunday 17 July 2005 00:06, Bernard Li wrote:
> Hey Erich:

> Is there any particular reason why udpcast is distro-specific?  I would
> imagine that the one compiled under RHEL3 will work for all the other
> distroes, in which case it should really be moved back to the RPMS
> directory.

> I tested the RHEL3 RPM on FC3 and it works fine.

in principle almost every binary package is distribution dependent due to the
required libraries and the provides/requires in the RPMs. Also noarch packages
can be distro dependent, for example when something like the python version is
hardwired in a script by some makefile. Now udpcast is pretty compatible as it
only depends on some glibc libraries. But does every distro you can think of
fulfill the requirements?
  distro/rhel3-i386> rpm -q --requires -p udpcast-20050226-1.i386.rpm
  /bin/sh
  libc.so.6
  libc.so.6(GLIBC_2.0)
  libc.so.6(GLIBC_2.1)
  libpthread.so.0
  libpthread.so.0(GLIBC_2.0)
  libpthread.so.0(GLIBC_2.1)
  libpthread.so.0(GLIBC_2.2)
  libpthread.so.0(GLIBC_2.3.2)
  rpmlib(CompressedFileNames) <= 3.0.4-1
  rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Right now it may, for distros currently supported by OSCAR... OTOH, how well
can we test something? Can we risk that the packages compiled under one distro
have rare problems under another distro because of some difference in the API
or the include files which the RPM build process didn't catch? Rocks is
limited to one distro, there is no such issue there. I think OSCAR should play
safe and better recompile binary packages for each supported distro. But maybe
I'm paranoid here, because I'm afraid of having to debug packages which I
didn't develop...

Additionally disturbing: keeping binary RPMs in the packages/*/RPMS directory
means to mess up the /tftpboot/rpm directory with RPMs for different and
useless architectures. Now we have three. It would be nicer to get really only
the RPMs which are needed copied into /tftpboot/rpm.

If you want to get support for heterogeneous setups (multiple architectures or
distros managed by the same master node), you should better keep the
architectures and distros well separated. You might want to end up with
/tftpboot/rpm-rhel4-x86_64
/tftpboot/rpm-fc2-i386
and the easiest way to copy in the necessary RPMs is to have them nicely
separated by distro and architecture.

Best regards,
Erich

Reply via email to