On Fri, Jun 07, 2002 at 08:19:47PM +0200, Thor Anthrax <[EMAIL PROTECTED]> wrote: > > [...Gordon Rowell...] > > No, source RPMs are actually really important. They allow other > > people to patch the files and build new RPMs. Without the source > > RPM, there is no history of the changes other make as the RPMs > > only include the "fixed" files. > > Scripts ARE open... readable and adjustable for everyone.
No, that's a different issue. Our code is in Perl, and readable. But you should make any modifications to the source RPM, not the installed files. It's pretty clear the reason for source and binary RPMs when the code is compiled, but the _same_ thing applies to shell and Perl scripts. If we only published "binary" (normally noarch) RPMs for our packages and someone on devinfo wanted to patch them, they would need to patch the file in situ, complete with changes. There is no history of the changes, and it is time consuming to fold those changes back into the main development stream. With one person making a patched version, it's just time consuming. With many people making patched versions, it can quickly become impossible to disentangle conflicting patches and the maintainers/original authors often just won't find that time. However, if the source RPMs are available, people can: - Use rpm -i to install the sources - Build a patch - Add a patch directive - Change the version - Rebuild the package, including the patch and new version Multiple people can build their own versions, each with clean patch histories, which are relatively easy to merge. The maintainers can then cleanly see the patches and apply them in sequence, accepting or rejecting changes. There is also, hopefully, some history in the %changelog to say what was changed and why. Strongly related to this is that you should always build on top of other work with patches - please don't rebuild the tarball. If you do that, the maintainers have to perform the time-consuming diff and patch to apply your patches. That makes it far less likely that your patch will be accepted as it's hard to see how and why you made it. In summary, - Use patches - Don't rebuild the tarball unless it's unavoidable - Make sure you change the version/release number - Release the source RPMs - Let the original authors know about your patched version - For us, [EMAIL PROTECTED] is a good place - if you patched it, it's probably for a reason :-) Gordon -- Gordon Rowell [EMAIL PROTECTED] Director, Engineering Network Server Solutions Group http://www.e-smith.com Mitel Networks Corporation http://www.mitel.com -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
