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. 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, 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. [rest deleted for brevity] -- R; ---------------------------------------------------------------------- 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
