Jorge M. wrote: > I have been creating a single RPM, including the binaries for all Linux > platforms and using scripts to copy the right set of binaries to our app > "bin" folder and removing all other platform binaries. That is completely in conflict with the idea of using native installers IMNHO. Basically you are working against the package manager. As a consumer of these I *hate* those types of rpms and would reject them and would feel the need to repackage them myself in order to use your product. > Nevertheless, the built-in dependency processing does not allow me to > install the package because all lib dependencies for all platforms cannot be > satisfied. That is correct because you probably can't satify all of the dependencies all of the time creating an empty set. > I need some advice. Should I break my package into multiple RPMs? Yes. Strongly advise yes. > I would really like to minimize the number of RPMs that I need to create. > Is it "wrong" to create a single RPM for all OSversion-architecture ? How > do I avoid the dependency checking? Should I follow a different path? Build on the oldest common denominator that runs on all of your supported systems. That will most likely run on later platforms. The one particular place where it does not is when libraries change and the older one is removed from newer systems. You would need to build a new rpm on that system for use forward of that point then. > Since we support multiple OS and we decided to use native > installers, Supporting native installers is good. But personally I feel that if they are not going to be used natively then it is better simply to supply an image file, such as a tar.gz image. It is better to play it plainly and honestly rather than simply giving "lip service" to using a package manager if it is simply going to be faked. > we are having a big learning curve, since we need to be well versed > in creating RPM packages for Linux, MSI installers for Windows, > Solaris packages and SD packages for HP-UX. Minimizing the > complexity on the packaging is key for maintainability You have set up a big job ahead of you. But taking shortcuts actually makes things harder and creates problems. Bob _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
