Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This is a very general question about best practices for creating RPMs for RHEL5 or RHEL6 and how to control which are installed where. Here's the detail:
I had an RPM for installing some software on RHEL5 and that worked fine. To get it working properly on RHEL6 I had to recompile it, which also worked fine. However, I now have two versions of the RPM, one that only works on RHEL5 and one that only works on RHEL6. My questions are:
1. How do I control where these packages can be installed?
2. What's the best naming convention for the packages to make it obvious which version is installed?
3. What's the best approach to the version/release issues?
Some of my thoughts on those questions are:
1. I can't use dependencies as I don't want to trigger an OS upgrade. I could put something in the pre-exec script, but that's a little bit hidden and maybe there is a more visible way that uses integral RPM features?
2. I could incorporate el6 in package name or release, but I'm not sure which is best.
3. I could put el6 in the release name, but then if the two packages have the same name it will cause me problems deploying them.
Incidentally I am keen not to bring anything unneeded with me from RHEL5 to RHEL6, which is why I haven't included any details on how to get the RHEL5 package working on RHEL6 (I know how to do it, but don't want to). I suppose I could get the RHEL6 package working on the RHEL5 servers and thereby have just one package, but that's a lot of work for no real gain, so I'm not keen on that approach either.
Apologies for how general this question is, but thanks in advance for any assistance.
You might want to at least setup a dependency on redhat-release* package as that will let it know if it is being installed on RHEL5 or RHEL6 server. Dependencies don't trigger updates from RHEL5 to RHEL6 so far as I know.
@MensaWater - I couldn't see how those packages worked, so I just tried installing the el5 version on an el6 server and it installed. So, I take the point of el6 being in the release name is useful, but there is no mechanism there to prevent installation.
@bigrigdriver - that's a really useful doc thanks. I went through it all, but didn't see any answers about what I was looking for. However, that was still very useful and I now conclude that there is no elegant solution to this that I have been missing.
So, I guess the answer to my original question is this:
First decide if this is one RPM or two - if it's one the RPM name will be the same and the release will differ (contain el5 or el6), but if it is two the RPM name can contain -el5 or -el6. Then through pre-exec scripts implement action based on the content of redhat-release that prevents installation on the wrong version.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.