Description of problem: * The redefinition of _localstatedir and _libexecdir seems quite wrong to me. * The perl requires should be along perl(NKF) >= 1.70 * the %define _use_internal_dependency_generator 0 is wrong because many dependencies are not caught that way. It should be instead along %define __perl_provides ..... and also certainly %define __perl_requires ..... * the devel and cgi package should certainly Requires: %{name} = %{version}-%{release} * is the static lib useful? * in multiarch settings it is nice to keep all the timestamps and have timestamps the same for both arches to avoid spurious timestamp differences with rpm -V. * the mv $RPM_BUILD_ROOT%{_sysconfdir}/namazu/namazurc-sample \ $RPM_BUILD_ROOT%{_sysconfdir}/namazu/namazurc is followed by a sed that rechanges the file. I suggest changing %defattr(-, root, root) to %defattr(-, root, root, -) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Fixed in 2.0.17-3.fc9.
In case you didn't get my mail: You should certainly redefine __perl_requires and __perl_provides to avoid bogus Provides and Requires. Currently namazu cannot be updated: Error: Missing Dependency: perl(time.pl) is needed by package namazu Error: Missing Dependency: perl(util.pl) is needed by package namazu Error: Missing Dependency: perl(document.pl) is needed by package namazu Error: Missing Dependency: perl(nmzidx.pl) is needed by package namazu Error: Missing Dependency: perl(var.pl) is needed by package namazu Error: Missing Dependency: perl(conf.pl) is needed by package namazu
Also you should have a look at http://fedoraproject.org/wiki/Packaging/Guidelines#head-5d1681fa7cf3714ad490fbf7c095a0cfe16da27f It is relevant for that case in my opinion. My personal advice would be to put it in /usr/lib/namazu/namazu.cgi since it is an arch specific file.
(In reply to comment #2) > In case you didn't get my mail: > > You should certainly redefine __perl_requires and __perl_provides to > avoid bogus Provides and Requires. Yes, that was my fault and forgot to do that. should be already fixed in 2.0.17-4.fc9. (In reply to comment #3) > Also you should have a look at > http://fedoraproject.org/wiki/Packaging/Guidelines#head-5d1681fa7cf3714ad490fbf7c095a0cfe16da27f > > It is relevant for that case in my opinion. My personal > advice would be to put it in /usr/lib/namazu/namazu.cgi > since it is an arch specific file. I see. thank you for the information. fixed in 2.0.17-5.fc9.
The %{_bindir}/nmz-config timestamp isn't still kept, though this is important since it is in -devel and installed in multiarch settings. This is because the patch has already messed the timestamp. You can do, for example in prep: touch -r nmz-config.in.multilib nmz-config.in There are noarch files in the namazu package that won't have the same timestamps on multi arches, however only one arch should be installed as long as there are only multilib settings. (it seems to me that they are generated from .in files). Instead of having Obsoletes: %{name} < 2.0.17-3%{?dist} in -libs, I would suggest adding in the main package: Requires: %{name}-libs = %{version}-%{release} This should achieve the same goal more cleanly, and additionally ensure that an update of namazu brings in the latest -lib package. There is a comment that seems wrong: ## recompressed with bzip instead of gzip The %config files should be (noreplace). Some files could be converted to utf8 (not necessarily all). Also (post should be for -libs instead of main package): namazu-libs.i386: E: library-without-ldconfig-postin /usr/lib/libnmz.so.7.0.0 namazu-libs.i386: E: library-without-ldconfig-postun /usr/lib/libnmz.so.7.0.0 namazu-cgi.i386: W: summary-not-capitalized a CGI interface for Namazu
(In reply to comment #5) > The %{_bindir}/nmz-config timestamp isn't still kept, though this > is important since it is in -devel and installed in multiarch > settings. This is because the patch has already messed the > timestamp. You can do, for example in prep: > > touch -r nmz-config.in.multilib nmz-config.in Indeed. there seems to be a bug in multilib-cmp.py then :) > Instead of having > Obsoletes: %{name} < 2.0.17-3%{?dist} The above line should be the recommended way to ensure an upgrade with yum. > in -libs, I would suggest adding in the main package: > Requires: %{name}-libs = %{version}-%{release} > This should achieve the same goal more cleanly, and additionally > ensure that an update of namazu brings in the latest -lib package. I think that that doesn't necessarily require exactly the same VR to use.
(In reply to comment #6) > (In reply to comment #5) > > The %{_bindir}/nmz-config timestamp isn't still kept, though this > > is important since it is in -devel and installed in multiarch > > settings. This is because the patch has already messed the > > timestamp. You can do, for example in prep: > > > > touch -r nmz-config.in.multilib nmz-config.in > > Indeed. there seems to be a bug in multilib-cmp.py then :) Why? > > Instead of having > > Obsoletes: %{name} < 2.0.17-3%{?dist} > > The above line should be the recommended way to ensure an upgrade with yum. It is recommended when a package disappeared. But namazu hasn't disappeared in that case. So upon update the -libs will be installed if namazu depends on that package without the need of an Obsolete. > > in -libs, I would suggest adding in the main package: > > Requires: %{name}-libs = %{version}-%{release} > > This should achieve the same goal more cleanly, and additionally > > ensure that an update of namazu brings in the latest -lib package. > > I think that that doesn't necessarily require exactly the same VR to use. Not to use, but it removes the need for a dubious Obsolete since namazu-libs doesn't really obsolete the old namazu, since some of the old namazu functionalities are in the new namazu package. And even though it isn't necessary to bring in the same VR, it is safer to require the same exact version because they are really meant to be installed from the same build. Imagine that there is a patch that corrects a security issue in -libs and the user only yum update namazu. Then the new -libs won't be installed. Also if you don't like requiring the same VR, you can Requires: %{name}-libs >= 2.0.17-3 instead of the wrong obsolete. But really I can't see what's wrong with requiring the namazu-libs that comes from the same build.
(In reply to comment #6) > (In reply to comment #5) > > The %{_bindir}/nmz-config timestamp isn't still kept, though this > > is important since it is in -devel and installed in multiarch > > settings. This is because the patch has already messed the > > timestamp. You can do, for example in prep: > > > > touch -r nmz-config.in.multilib nmz-config.in > > Indeed. there seems to be a bug in multilib-cmp.py then :) I understand what you said, now that I remembered what multilib-cmp.py is... I don't think this is a bug since multilib-cmp.py only checks for file conflicts, not timestamp differences. It could also check for timestamps, sure.
(In reply to comment #7) > It is recommended when a package disappeared. But namazu hasn't > disappeared in that case. So upon update the -libs will be installed > if namazu depends on that package without the need of an Obsolete. That was introduced for the case splitting out the libraries to the sub package, anyway. I forgot where it was posted but it's mentioned at: http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#head-00ee522736f170188d55557040371ff66d365061 > And even though it isn't necessary to bring in the same VR, it > is safer to require the same exact version because they are really > meant to be installed from the same build. Imagine that there is > a patch that corrects a security issue in -libs and the user only > yum update namazu. Then the new -libs won't be installed. yum does pick up the updated namazu-libs too unless users explicitly excludes it. but this is likely on other packages too. does the maintainers explicitly have the versioned dependencies instead of the file dependencies from rpm for all the shared libraries not to get scared the unknown security issues? (In reply to comment #8) > I understand what you said, now that I remembered what > multilib-cmp.py is... I don't think this is a bug since > multilib-cmp.py only checks for file conflicts, not > timestamp differences. It could also check for timestamps, > sure. My understanding is, multilib-cmp.py is supposed to be checking the multilib issue, but not just checking the file conflicts, but anyway :)
(In reply to comment #9) > (In reply to comment #7) > > It is recommended when a package disappeared. But namazu hasn't > > disappeared in that case. So upon update the -libs will be installed > > if namazu depends on that package without the need of an Obsolete. > > That was introduced for the case splitting out the libraries to the sub package, > anyway. I forgot where it was posted but it's mentioned at: > http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#head-00ee522736f170188d55557040371ff66d365061 Grrmph. Ok then, I indeed remember lots of messages about multiarch issues that were fixed by this trick. It is unfortunate, but I don't know those issues well, so let it be. > yum does pick up the updated namazu-libs too unless users explicitly excludes > it. but this is likely on other packages too. does the maintainers explicitly > have the versioned dependencies instead of the file dependencies from rpm for > all the shared libraries not to get scared the unknown security issues? The point here is that it removed the need for a dubious obsolete and had the added benefit of ensuring that the libs and the main package were always in sync. Now if we have to workaround yum or something else bugs by putting wrong obsoletes, then indeed it is unneeded. Unless I am wrong everything I pointed out is fixed, closing.