Hello Michael, > Your spec file is missing %defattr statements in the %files section. Due to > that, currently all files in your binary rpms are owned by user leonard > group leonard. That is ugly. Sorry for that. Fixed it already, and made new rpm's available via http://www.ottolander.nl/opensource/mcrypt/mcrypt.html . In my defence I must say that a %defattr statement is missing from the SUSE srpm. Possibly rpm's at SUSE are all build as root. They don't seem to have heard of (Build)Requires either, although they do comment the SPEC file with requirement info. > you could use: > > CFLAGS="$RPM_OPT_FLAGS" %configure --enable-static Indeed less cluttered. Fixed this as well. > I'd recommend %setup -q to untar the source tarball quietly (this makes > build logs smaller, too). Yup. Done. > My personal point of view with regard to RPM macros in "Patch:" fields is, > it doesn't make much sense to use macros there. Usually there is no need to > update a patch with the next upstream version of the software. And hence > there is no need to make patch file names depend on the software version. > Instead of e.g. libmcrypt-%{version}-notdynamic.diff, I would use a generic > name or a hardcoded version. I guess you are right again. Patches are usually version specific and actually I don't like generic patch names anyway, naming them related to their functionality makes maintenance easier. Blaim SUSE again ;). Fixed the patch versioning, and split the libmcrypt patch. Dropped one of three hunks because it introduced a redundant declaration and got rid of the commented code in the patch file (ugly). > Rule of thumb: Only update packaged files and the spec file where necessary. ... That seems obvious... > If you want users and reviewers to be able to verify the included source > tarballs easily, include a complete macro-free URL to the Source tarball, > either directly in the "Source:" fields or as comments above. Problem is currently I use the bzipped tarballs from the SUSE rpm, which can be found at my website. Gzipped tarballs can be found at http://sourceforge.net/projects/mcrypt (URL included in the SPEC file), might use these in a later version. One oddity I found is that the libmcrypt-idea tarball is not available via Sourceforge (anymore?). I contacted Tomas Chrak about this, but didn't receive an answer yet. Finally a question for you. I would like to get rid of the autoreconf in the mcrypt SPEC file. It currently requires CVS, although I don't see the use of a CVS update of a package with a fixed version. Do you think I can safely delete it? What is it doing anyway? Just removing autoreconf from the SPEC file caused a versioning problem with automake. Guess I'll have to wade through the configure script and see if I can find a clue there. Always surprised how big they are in comparision to the actual package. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
