Bug 383521 - some packaging issues
some packaging issues
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: namazu (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-14 16:55 EST by Patrice Dumas
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-29 16:25:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Patrice Dumas 2007-11-14 16:55:27 EST
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:
Comment 1 Akira TAGOH 2007-11-19 22:06:24 EST
Fixed in 2.0.17-3.fc9.
Comment 2 Patrice Dumas 2007-11-22 08:34:48 EST
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


Comment 3 Patrice Dumas 2007-11-22 08:44:50 EST
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.
Comment 4 Akira TAGOH 2007-11-25 01:29:16 EST
(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.
Comment 5 Patrice Dumas 2007-11-26 17:28:31 EST
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

Comment 6 Akira TAGOH 2007-11-26 21:26:20 EST
(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.
Comment 7 Patrice Dumas 2007-11-27 03:37:46 EST
(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.
Comment 8 Patrice Dumas 2007-11-28 13:30:47 EST
(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.
Comment 9 Akira TAGOH 2007-11-29 07:49:22 EST
(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 :)
Comment 10 Patrice Dumas 2007-11-29 16:25:50 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.