[Fontconfig] fontconfig.spec fixes

[John A. Boyd Jr.]

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