Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
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.
I have been trying to fix up a spec file for some xemacs packages so that it properly installs all of its info files.
The problem is that there is a set of info files that are installed, but that never get install-info invoked on them.
What I would like to do is to say (in the %post script)
Code:
for all info files being installed to %{_infodir}
/sbin/install-info $f %{_infodir}/dir --section="Xemacs"
and then the inverse for the %postun script.
Unfortunately, I'm not sure how to translate "info files being installed to %{_infodir}" into bash code. Can anyone advise me?
Similarly, I need to translate "info files being removed from %{_infodir}" into bash code, and I have, if possible, even less notion of how to do that task.
I have had a look at the Maximum RPM book, but its examples of scripting are pretty limited, and don't seem to describe any environment variables, bound in the scripts, that would help with this. I would have thought that there would some way be access to the file list in the scripts, but I have not been able to determine what this is, if it exists.
Unfortunately, Maximum RPM is severly out of date, but updated documentation is available online here. The script you want to run is almost complete as is. Here is what the xemacs script for Mandriva does with the info files:
for f in /usr/share/info/xemacs/*.info.bz2; do
/sbin/install-info $f /usr/share/info/dir --section="XEmacs"
done
Unfortunately, Maximum RPM is severly out of date, but updated documentation is available online here. The script you want to run is almost complete as is. Here is what the xemacs script for Mandriva does with the info files:
Code:
for f in /usr/share/info/xemacs/*.info.bz2; do
/sbin/install-info $f /usr/share/info/dir --section="XEmacs"
done
Hope this is helpful
I have looked at the Red Hat documentation as well. All the documentation on RPM that I can find is distressingly vague about what is the precise environment in which post install scripts will be evaluated. For example: What environment variables are available? What macros (%files?) may be employed? What directory will you be in?
The problem with the above script snippet is that xemacs also installs some files in /usr/share/info (as well as /usr/share/info/xemacs). The info files in /usr/share/info are not correctly indexed.
AFAICT, I cannot simply do:
Code:
for f in /usr/share/info/*.info.bz2; do
/sbin/install-info $f /usr/share/info/dir --section="XEmacs"
done
...because if I do I will pick up not only the info files installed by xemacs, but also all the info files that are already there, turning the info directory into a mess. So the open question is "how do I find a list of the newly-added info files?" I don't see anything in the RPM docs that tells me how to do this...
Note that this problem does not arise in the code snippet you offered, because the packagers have carefully put those info files into a pristine new directory (/usr/share/info/xemacs).
I guess I'd have to see your spec file. The snippit I got was from the rpm's post script, not the actual spec file. I assumed from other spec files I do have that this should work if you manually install the info files during the install process of building the rpms. I'll check it more thoroughly when I get home from class.
Yes, I believe that would work for FSF emacs, which is distributed rather differently. Unlike FSF emacs (AFAIK), Xemacs provides packaging of a large set of emacs-lisp packages. This is a modified Mandriva RPM, and rather than trying to keep on top of the set of emacs lisp packages, Mandriva simply repackages the "sumo tarball," of xemacs lisp packages. This leads to the approach you see here, where an attempt is made to automatically find the info files and package them up into one big xemacs-packages rpm.
FWIW, if it's inelegant to package this way, trying to use FSF emacs on Mandriva has shown me the value of it. Instead of the sumo tarball, FSF emacs is packages with a flood of individual emacs-lisp packages, which are nightmarish to track and get installed. It's much nicer to just get one big rpm and install that.
A second problem, which I have just found, is that there can be a fair amount of collision between xemacs and FSF emacs info files, so it's all the more important to find all the info files and operate on them.
One possibility, it seems to me, would be to find all the info files during the build process, when they're easy to get your hands on (I know how to do this). The problem with doing that is that I don't know how to pass information from the build process into the install process. It seems possible to push information from the build process in the special case of writing a file and then reading it into the %files (the %files -f filename trick). I don't know if there's any similar trick to more generally record information during a build cycle and then use it later in the install process.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.