[ale] rpm's src vs binary and the confusion
scott mcbrien
smcbrien at gmail.com
Fri Jun 7 11:30:28 EDT 2013
Jim, Narahari is wanting to have the script both in the file manifest AND
call it as part of the %pre.
Narahari,
Not knowing why you're trying to do this I can't provide more specific
guidance other than putting the shell script's contents in %pre rather than
trying to call the (yet uninstalled) script file. I'm sure there's some
horrible hack to make it happen, but don't. Remember KEEP IT SIMPLE. If
you keep things simple your life down the road is much easier.
As for why your RPM isn't reloacatable, relocatable RPMs use a prefix
directory in their spec file which is used in front of all the file
locations in the %files section. You don't have a prefix set and your
%files are fully qualified, ie /opt/tomcat-.... A relocatable RPM would
use opt/tomcat-..., notice the missing leading /. The relocatable RPM will
stick whatever the prefix setting is in front of the file location. If you
set the prefix to /, then your rpm would install the same unless someone
used some options on the installation command-line to override the default
prefix. Now that you know why it doesn't work, DON'T EVER DO THIS. I have
a feeling you're trying to do multiple app server installs on the same box
(but again, not being told the goal, this assumption may be wrong), if
that's the case, RPM is probably not the best route for you to go.
Lets say you succeed in having your RPM relocatable, and you install 5
copies of it in different locations. You know how that looks in the RPM
database?
rpm -q apache-tomcat-vanilla
apache-tomcat-vanilla-7.0.37-1.0
apache-tomcat-vanilla-7.0.37-1.0
apache-tomcat-vanilla-7.0.37-1.0
apache-tomcat-vanilla-7.0.37-1.0
apache-tomcat-vanilla-7.0.37-1.0
So which one is which? You're going to have to do file queries (rpm -ql)
to figure it out. Additionally, when it comes time to upgrade, you're
going to have to update 5 separate instances and **guarantee** that you
upgrade with the right directory locations as options to your upgrade. (I
think I know understand your question from the other day about figuring out
where an RPM is installed to) So you can kiss tools like yum goodbye
because they don't have the options you'll need. Now that I think about it
more, I don't even know how you'd specify which of those you're even trying
to upgrade since they all are the same name/version. Maybe there's some
more query stuff that could nail it down, but wow, now things are starting
to get difficult.
Something else you might not have run into yet. If you're doing a bunch of
exotic scripting in your %pre, are you doing the reverse of that in your
%preun or %postun? You want to make it so that if someone erases your RPM
it leaves the system in the same state that it was before the RPM was
installed. Also, if someone does an upgrade of the RPM, some of the
scripts aren't run, so have you taken that into account in your scripting
as well?
Last note about scripting. You have to be really careful with it. I was
using a vendor provided RPM once that had this in it's %postun:
rm -f /lib/modules/`uname -r`/kernel/drivers/scsi/fc/lpfc.ko
The RPM overwrote the OS provided module with one of it's own, then in this
uninstall script attempted to clean that back up. But it's missing some
stuff. Like, where is it putting the original file that it overwrite back
into place? Also, the reason I found out about this particular little
nugget of crap was I updated the kernel on a machine to a version that no
longer required the vendor's proprietary driver. After verifying that the
new kernel was working, I removed this RPM. Which then removed the lpfc.ko
from my NEW KERNEL thanks to the uname -r call. The result was I lost all
connectivity to the storage array and my life sucked for a while as we had
a downtime that exceeded it's window. My point is that scripts in RPMs
need to be written in such a way that they don't rely on information that
is inaccurate. It's really easy to write scripts that work fine in
testing, then blow up in production because things aren't quite the same,
or the process for applying/upgrading/erasing RPMs is slightly different.
-Scott
On Fri, Jun 7, 2013 at 10:29 AM, Jim Kinney <jim.kinney at gmail.com> wrote:
> Shouldn't that script file just be part of your SOURCE and then processed
> during make to be a plain copy to final location , listed in %files?
>
>
> On Fri, Jun 7, 2013 at 9:19 AM, Narahari 'n' Savitha <savithari at gmail.com>wrote:
>
>> Ok, Thank you to all of you. I created my .rpm and tried it out. A few
>> questions still linger. Kindly help.
>>
>> My package is not a relocatable package, at least thats what the tool
>> tells me. What am I doing wrong that is making it Non-Relocatable ?
>> Here is the spec file.
>> http://pastebin.com/rFcE7Y05
>>
>> Also please take a look at this link.
>>
>>
>> http://stackoverflow.com/questions/7813436/rpmbuild-using-script-files-contained-in-the-package-in-pre-script
>>
>> In this the person who has replied says that Makeself allows you to
>> create a self installable executable which is base64encoded. But the
>> question is how do you put a script (aka .sh file) which is a part of the
>> .rpm file in the
>>
>> %pre section.
>>
>> If I want to put Source2:narahari.sh how do you make it available %pre as
>> in
>>
>> %pre -f narahari.sh
>>
>> Thank You
>> -Narahari
>>
>>
>> On Wed, Jun 5, 2013 at 12:04 AM, Jeff Hubbs <jhubbslist at att.net> wrote:
>>
>>> Meh. Admins rotate in and out so much these days and documenting
>>> things is so unheard of...don't get me started. Suffice it to say that no
>>> one will curse your name because no one will remember it. :)
>>>
>>> A few years ago I was trying to address a very unhealthy
>>> Tomcat-behind-Apache platform that was using some very old version of
>>> Tomcat that was so unstable that it was end-of-lifed and a whole new branch
>>> of the tree emerged with a "there be dragons" sign left at the old. :)
>>>
>>> The Apache people, over and over again, would say DON'T use your
>>> distro's package manager...just DON'T!!! And sure enough, on RH and
>>> -alikes, I could see why at the time. Whoever managed the Gentoo ebuild
>>> was very meticulous and it *would* work perfectly, but you could see that a
>>> "Tomcat way" and a "Gentoo way" of doing and placing things was being very
>>> carefully reconciled. Just the same, if you eschewed the Tomcat ebuild
>>> under Gentoo and just took the Tomcat distribution as the Apache people
>>> intended, there wasn't any interference and it would work just fine also,
>>> provided you'd laid in the dependencies by hand via Portage.
>>>
>>> On 6/4/13 8:40 PM, Jim Kinney wrote:
>>>
>>> +1e^infinity
>>> KISS principle keeps later admins from putting a price on your head.
>>> On Jun 4, 2013 8:21 PM, "Scott McBrien" <smcbrien at gmail.com> wrote:
>>>
>>>> I would attempt to dissuade you from using a delta rpm. With deltas,
>>>> you end up being really really concerned with versions. So after your
>>>> first delta gets applied, if you have another update, you make a delta of
>>>> the delta, which means if there's a machine with the vanilla rpm out there
>>>> and you apply delta2 on it, things devolve into madness quite quickly.
>>>> Does a regular RPM contain more stuff and take up more space? Sure. But
>>>> if an RPM is 10MB or 100MB, who really cares. The simpler you keep your
>>>> packages, the more independent you keep your packages the less likely that
>>>> you get into a situation you can't, or is extremely difficult, to reverse.
>>>>
>>>> If you choose to ignore my advice, you should use not only the
>>>> package name, but also the version in your Requires for your drpm, that
>>>> should keep you from applying a drpm to a box that is not at the
>>>> appropriate version to accept the delta successfully.
>>>>
>>>> But seriously, keep it simple, it will improve your life in the long
>>>> run, and admins who follow you will praise your good works rather than
>>>> spitting and cursing at the mention of your name.
>>>>
>>>> -Scott
>>>>
>>>> On Jun 4, 2013, at 7:23 PM, "Narahari 'n' Savitha" <savithari at gmail.com>
>>>> wrote:
>>>>
>>>> I built my vanilla Tomcat rpm and the %install section has
>>>>
>>>> mkdir -p $RPM_BUILD_ROOT/opt/
>>>> cp -R /home/virtual/rpmbuild/BUILD/apache-tomcat-7.0.37
>>>> $RPM_BUILD_ROOT/opt
>>>>
>>>> I also built the delta.rpm and I am in the process of tinkering the
>>>> %install section for that.
>>>> What I would like to do is
>>>>
>>>> a. check if apache-tomcat-7.0.37-vanilla is installed (this I can do
>>>> in the Requires section of the preamble, I presume the name is the name of
>>>> the rpm package)
>>>> b. enquire the rpm tool as to where the package
>>>> apache-tomcat-7.0.37-vanilla is installed ? not sure how to do this.
>>>> c. cd to the location the apache-tomcat-7.0.37-vanilla is installed
>>>> and backup a few files.
>>>> d. then do a cp -r from the BUILD folder to the target folder.
>>>>
>>>> Where should I put the code for all this ? I presume the %install
>>>> section ?
>>>> What all heavy lifting can I or should I do in the %install section and
>>>> is using macros a requirement or a good thing to do kind of a thing ?
>>>>
>>>> Kindly help.
>>>>
>>>> -Narahari
>>>>
>>>>
>>>> On Mon, Jun 3, 2013 at 3:31 PM, Scott Plante <splante at insightsys.com>wrote:
>>>>
>>>>> "Also, tomcat is not really built as in gcc or cc or whatever aka no
>>>>> make or configure."
>>>>>
>>>>> Mostly true, however there is an optional native part, found in the
>>>>> "[tomcat-root]/bin/commons-daemon-native.tar.gz" file. If you're creating a
>>>>> Tomcat binary RPM it would be a good idea to compile this, as it allows you
>>>>> to have Tomcat listen on port 80/443 (or a port <1024) directly without
>>>>> running Tomcat as root. You don't need this if you're running Tomcat behind
>>>>> Apache HTTP, but for example WebRTC won't work proxying through ajp.
>>>>>
>>>>> Scott
>>>>> ------------------------------
>>>>> *From: *"Narahari 'n' Savitha" <savithari at gmail.com>
>>>>> *To: *"Atlanta Linux Enthusiasts - Yes! We run Linux!" <ale at ale.org>
>>>>> *Sent: *Sunday, June 2, 2013 10:02:11 PM
>>>>> *Subject: *[ale] rpm's src vs binary and the confusion
>>>>>
>>>>>
>>>>> Friends:
>>>>>
>>>>> I am building an rpm for Apache Tomcat version 7.0.37.
>>>>>
>>>>> Sorry to ask a lame question but what is the diff between src rpm and
>>>>> regular rpm ?
>>>>> (dont flame, I know I have read it but it confuses me when I am
>>>>> building)
>>>>>
>>>>> Also, tomcat is not really built as in gcc or cc or whatever aka no
>>>>> make or configure.
>>>>>
>>>>> So in the install section what should I be really doing ?
>>>>> Spec file is here.
>>>>>
>>>>> http://pastebin.com/f6P64tSQ
>>>>>
>>>>> Also, if I have a custom name for the rpm I am building, what macros
>>>>> or env variables are available in the %install section ?
>>>>>
>>>>> Regards,
>>>>> -Narahari
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ale mailing list
>>>>> Ale at ale.org
>>>>> http://mail.ale.org/mailman/listinfo/ale
>>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>>> http://mail.ale.org/mailman/listinfo
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ale mailing list
>>>>> Ale at ale.org
>>>>> http://mail.ale.org/mailman/listinfo/ale
>>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>>> http://mail.ale.org/mailman/listinfo
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Ale mailing list
>>>> Ale at ale.org
>>>> http://mail.ale.org/mailman/listinfo/ale
>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>> http://mail.ale.org/mailman/listinfo
>>>>
>>>>
>>>> _______________________________________________
>>>> Ale mailing list
>>>> Ale at ale.org
>>>> http://mail.ale.org/mailman/listinfo/ale
>>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>>> http://mail.ale.org/mailman/listinfo
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ale mailing listAle at ale.orghttp://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
>>>
>>>
>>>
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>>
>>>
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
>>
>
>
> --
> --
> James P. Kinney III
> *
> *Every time you stop a school, you will have to build a jail. What you
> gain at one end you lose at the other. It's like feeding a dog on his own
> tail. It won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
> *
> http://electjimkinney.org
> http://heretothereideas.blogspot.com/
> *
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130607/4a703d09/attachment-0001.html>
More information about the Ale
mailing list