pesarif wrote: > Hi. > > I just read some bits and pieces from an open-book called "Maximum RPM". It > mentions that to build an RPM from .tar.gz source, you need to have a section > called "%files" in the .spec file and that this must list _all_ the files > that will be installed on the user's system. The book is a little dated, so > is this still true?
http://www.linux-mandrake.com/en/howtos/mdk-rpm/ QUOTING: 4.4.5. Files section %files This section consists of a list of files that will be picked from our simulation directory tree to be packed into the package. See the fine manual for the different options not being used in that simple example. The file list must be written by hand in the spec file. It may be constructed by listing all files created by rpm in the build directory tree. In order to do that, issue a rpm -bi mypackage.spec in order to stop the building process just after the simulated install. Then, look in the simulated installation directory, ~/rpm/tmp/gif2png-buildroot in our case, to see which files you want to put in your package (most of the time, you will put them all). Note that you should never use find to build a list of files to include but explicitely list all files (this'll show up bugs in new versions). The only exceptions is for locales for which you should use %find_lang %{name} in %install section and replace %files by %files -f %{name}.lang (see Appendix B). Note about directory structure: The files being installed by your package "should" follow the FHS recommendations at http://www.pathname.com/fhs %defattr(-,root,root,0755) This tag defines the attributes to be applied to each file being copied to the user's system. The four arguments given means: * -: all the attributes for regular files are remained unchanged, * root: the owner of the file is root, * root: the group of the file is root, * 0755: the attributes applied to all directories owned by this package are 0755. %doc README NEWS COPYING AUTHORS The special tag %doc designates files being part of the documentation of the package. The files so-called will be placed in /usr/share/doc/gif2png-2.0.1/. This directory will be also automatically created. Files specified by %doc are relative to your untarred source directory in BUILD. %{_mandir}/man1/gif2png.1* %{_mandir}/man1/web2png.1* Here also it is recommended to list each man or info file separately. [Note] Also you may wonder why telling gif2png.1* and not gif2png.1.bz2. This is to preserve compatibility with other systems that could use gzip compression instead of Mandrake bzip. If you find such referencies to bz2 compression into spec files, change them to a wildcard. Most of the time you can even use %{_mandir}/man1/*, this will take all the files it can find. %{_bindir}/gif2png %{_bindir}/web2png As you can see, you have macros for every kind of path you need. Here are the most useful ones (look at /usr/lib/rpm/macros for everything) : %{_prefix}, %{_bindir}, %{_sbindir}, %{_datadir}, %{_libdir}, %{_sysconfdir}, %{_mandir}, %{_infodir}. For games, use %{_gamesbindir} and %{_gamesdatadir}. > > I mean, if I'm compiling something big like KDE (not from SRPMS), it's kind > of impractical to know what all the %files will be. So does anyone have any > ideas on how to approach this problem? Otherwise building RPMs (using > customised source) will be a nightmare :( Sorry, the %files is required and must be built by hand. I had over 100 listed for xbasic. It is what keeps conflicts from destroying your system outright with no warning. If you think that is a stiff requirement, check out the preparation of .deb files. > > Secondly, I noticed in a number of posts that people have mentioned that i686 > (Pentium II) packages will run on a Pentium (i586). If gcc does > processor-specific optimisations (e.g. use of new instructions), then how > could i686 packages possible run on i586? There are two levels of such optimizations--first is optimizing and the second is compiling for exclusively. These are to some extent compiler dependent. i686 files often show a loss in performance even on i686 machines over the i586 counterparts, perhaps because i686 instructions were thought up by marketing geniuses at Intel rather than deliberately designed by engineers (whoohooo, am I ever getting cynical...) Athlon rpms are almost worth the trouble for specific compilation, but I have yet to find a case where i686 compilation actually improves performance. It is the same with MMX. Software has to be specifically crafted to take advantage of MMX instructions, not just a compiler flag set, though that may provide a modicum of help for a well-written compiler. Civileme > > Thanks in advance > pesarif > > > > > ------------------------------------------------------------------------ > > Want to buy your Pack or Services from MandrakeSoft? > Go to http://www.mandrakestore.com >
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
