Rick Troth wrote:
I said:
Build the package outside of RPM control. That is, DO NOT ship it
as built from the SRPM. You can and should still ship an SRPM.
Do an 'rpmbuild -bb' against a built and installed package.
John then said:
I _hate_ packages built this way. I fully expect that, should I rebuild,
I can do so from the source rpm, and that the result will be equivalent
to the binary rpm.
Please understand, I did not say that Kirk's CUSTOMES could not rebuild,
nor that they should not use SRPM to do so, nor that Kirk's team should
not use the SRPM in various ways during development. I only said that
the RPM(s) delivered should be built outside of the too-smart-for-itself
logic of SRPM based builds.
The source rpm is the source from which a user ought be able to build
binaries the supplier supports in the same way the supplier supports the
actual rpm it shipped. Where source is provided, as in this case, then
it should include all the actual source and build procedures needed in
order to produce the binaries.
Given that, the customers can in principle fix problems themselves.
An example where this was important: a bloke I was talking to a few
years ago had a contractor provide some software. The contractor
retained the source; the contractor died and either the user's
requirements changed, or there was a problem. Either way, the bloke was
stuffed.
RPM as a whole gets waaaayyy to intimate with the loader.
For payload delivery, RPM is fine. (And proper registration, and for
audit, and a host of things I can hear Mark Post saying "must have!".)
It's the all to often flawed BUILD automation in the RPM suite that
produces executables with distro-specific and release-specific bondage
that _I_ hate.
I don't like any Sun or IBM java rpm I've seen (IBM's are better)
because they play tricks building them.
Dunno what "tricks" they play,
Is this an rpm, or is it not an rpm:
downloads/jre-1_5_0_01-linux-i586-rpm.bin
It's an rpm imbedded into a shell script - think shar - and it does all
sorts of stupid things. An rpm I can examine with various incantations
of the rpm command; I can view a list of its contents, I can see what
the vendor thinks it does, I can view the changelog to see if it's got
the recent WA TZ changes in it, and I really want I can convert it to a
CPIO archive and unpack it without installing it.
About the only thing I want to do that to is this stupid package;
because it's unusual, I wonder about it.
but don't write off the whole -bb lot based on that, John!
As a vendor, Kirk surely does not want to have to produce
a separate RPM for each distro/release combination.
Kirk's choice of course, but he absolutely needs builds for RHEL 4, 5
and SLES 9, 10 for zSeries. The RHEL ones will do fine for CentOS (a
major point of CentOS is binary-compatibiity with RHEL) Earlier releases
could maybe be done when demanded.
If the rpms are relocatable and the package is built to be configurable
around the differences between SUSE, RH, Debian etc, then one rpm might
well do for equivalent releases of SLES and RHEL.
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
Please do not reply off-list
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
