Jeff Johnson wrote: > Wyse, Chris wrote: > > I have a customer that would like us to stop using source RPMs for > > distribution. He says that many Linux distributions do not support > > SRPMS. Does anyone know which distributions do NOT support SRPMS? > > All linux distros that don't use rpm don't support srpm's. Debian and Ubuntu come to mind immediately and there are many others. But as I am sure Jeff was thinking the term "support" means different things at different times. The system may be technically able to install .rpm files or rebuild .src.rpm files but if you do then you mess up your system to the point that you don't really want to do that. > >Also, I distribute a carefully crafted RPM that supports SUSE 9.2, > >9.3, 10, SLED 10, openSuse 10.2, RHEL3, RHEL4, RHEL5, FC4, FC5, and > >FC6. Is this the typical way to distribute software on Linux? Yes. But also providing simple things like .tar.gz files helps all software distributions that are not one of those listed. Sun's Java is one example that also releases a binary blob file. > > Should I also release a tarball? Or use some other method? Comments? Without even knowing your application I will ask please do. > All depends on whether the list above covers your desired customer base. > > Likely a *.deb (or carefully examining alien rpm -> deb conversion) > might be needed. > > Tarball's are certainly a universally supported distribution format. It is more important to follow the FHS and LSB and to install into the correct locations than to release a generic tar.gz file. I really hate poor quality .rpm files from 3rd party vendors. I am often forced to repackage them into something more palatable. But a good quality .rpm or .src.rpm file can be a fine base for installation onto a non-rpm software distribution. A well behaved standards conforming rpm file can usually be installed with 'alien' on a Debian system. I am okay with that. But a bad rpm file needs repackaging even on native rpm systems. For example, don't hard coded paths to /bin/basename or /usr/bin/grep and others in scripts and other places. (Why do people feel the need to do that? Remember that while you might be able to make things "foolproof" you won't be able to make them "damn foolproof" so it is better not to try.) Simply call commands and find them on PATH. They will be in /usr/bin/basename or /bin/grep on other systems. I am just picking on those as classic unix-like examples but the problem is generic. For example don't install into /usr/local/bin. The FHS says that is reserved for the local admin. Developing there is fine. But once you start distributing your application outside of your use then the FHS applies so that everyone can work together. For example don't _require_ the user to set environment variables to run. If environment variables are required then use a script wrapper to set them. This often manifests itself as /etc/profile.d/foo.sh scripts. Other systems don't need require users to log out and back in again to use recently installed software and don't use a profile.d directory. For example don't include the same set of files in multiple rpm files. Sure rpm allows it if the md5sum is the same but it is a bad thing to do regardless. For example don't try to interact at rpm installation time. If you need post installation configuration you will need to provide a post installation configuration script or other process. For example don't reach into $HOME of the user installing the rpm and modify files in that user's home directory. The admin installing the rpm is very likely not the user who is going to use the rpm. The user disk may be on NFS without root access at installation time. Bob _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
