Hi Enrique, Enrique Perez-Terron wrote: > > I looked up in http://www.rpm.org/RPM-HOWTO/build.html, and found: > > "%dir marks a single directory in a file list to be included as being > owned by a package. By default, if you list a directory name WITHOUT a > %dir macro, EVERYTHING in that directory is included in the file list > and later installed as part of that package." > > It seems like the function of the %dir directive is to mark the > directory as owned by the package, so it will be deleted when the > package is uninstalled, and its permission bits are checked when the > user runs rpm -V. > My experience is that rpm-installed directories are not deleted in any case if something is in them that was not part of the package. Otherwise, e.g., you could use a '%dir %{_libdir}' directive, and it would delete /usr/lib (in the default case) when the package is removed; that doesn't happen. > >>Two other things: first, I suspect the name of the package >>is 'fontconfig', so you could replace 'fontconfig' in the >>above with '%{name}' consistently (and the form then corresponds >>to 'pkgincludedir' in automake usage), i.e., >> >> %{_includedir}/%{name} > > > This seems like a good point to me. However, I feel this kind of things > should be done by the maintainer, not by me who only looked into this > package just enough to find out how to get the rpmbuild -bb to run > through to completion. > > This sounds like another good point, but again I feel the maintainers > should decide the version numbers, not random contributors like me. If > the maintainer accepts my patch, or some doctored version of it, the > file fontconfig.spec.in will get a new version number in CVS quite > automatically. > > I guess the maintainers will bump the version number of the package when > they reach a new stability point, e.g., a full make completes > successfully. Since I made my change relative to version 2.2.2, it is > quite possible that my patch doesn't work with the current cvs. In fact, > I just tried it, and found that the man/man5 directory has mysteriously > disappeared, resulting in rpm build errors. I'll debug that next. > > Otherwise I feel that keeping a very detailed log of single-file changes > in the file itself can be a nuisance, given that such information can be > tucked into the cvs log. I suppose that I don't have write permission > for the cvs (haven't tried), so again it will be the maintainers that > will have to decide what to do with this. > I would make another suggestion if you'll allow me: rpm spec files are for your use and convenience, not the maintainers'. The basic original point of RPM was to allow an individual user of a package (i.e., you) to maintain the "pristine" sources (i.e., the fontconfig tarball that Keith or whomever else makes available), and for you to track your local changes, build preferences, etc., without having to change what the tarball maintainer provides. This is how RedHat designed it, and how RedHat uses it. The version number belongs to the maintainer, but the release number (and epoch, and serial) belongs to you, for your use in tracking your changes. The spec file and the patch files you develop for your own purposes become your detailed log of changes, and that was the intent of RPM. Thus, a spec file is your alternative to having write access to the maintainer's CVS or other source control repository. This is a philosophical point, I admit, but a fundamental one. It's good that some maintainers package spec files in their tarballs, but if that was the only way they were ever used, the %patch directive would be useless (and, I would suggest, the use of multiple sources would be useless as well). Indeed, your use of a release number has the potential of clashing with one the maintainer uses, but there is a convention for that as well: Release: 0 I.e., the spec file included in a tarball, without patches and with the intent of serving only as an alternative to a manual build, should have a release number of 0. Otherwise, you can use, say, your initials as a release suffix, if you are trying to synchronize with some other provider of (binary) RPMs. Finally, if you at least maintain your own patches against the pristine sources of the maintainer, then you have a better chance of being able to update those patches for new maintainer releases, if the maintainer hasn't in fact adopted your patches in the interim. In that regard, I would suggest you look into the use of the simple 'gendiff' script that is provided with the rpm distribution. > >>-John
