Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=457210 --- Comment #21 from Patrice Dumas <pertusus@xxxxxxx> 2008-09-03 07:20:36 EDT --- Definition of packagename as a macro is unuseful. The description of the dpkg subpackage should be trimmed to contain only what is relevant for that sub-package. For dpkg-dev you should not use -n, but instead use dev, dpkg- will be automatically prepended. A period is missing at the end of dpkg-dev %description. Although the Group doesn't matter much, it seems to me that dpkg-dev should better be Development/Tools. There is a spurious space before the period of the dselect. I suggest using a glob for the man pages extensions, such as not to have to change the spec file when the compression scheme changes or there is no compression, like %{_mandir}/man1/dpkg-deb.1* It seems to me that %{_libdir}/dpkg/ should better be in %{_datadir} or %{_libexecdir} than in %{_libdir}. Maybe this could be reported upstream? The admindir is /var/dpkg, it should be /var/lib/dpkg, you should pass configure --with-admindir=%{_localstatedir}/lib/dpkg Also the package should certainly own %{_sysconfdir}/dpkg, and have %{_sysconfdir}/dpkg/dpkg.conf %config(noreplace). Also %{_sysconfdir}/dpkg/origin/ and /usr/share/dpkg/ are not owned. Shouldn't dpkg-dev and dselect depend on dpkg? To keep timestamps on iconved files, you can do for file in %{buildroot}%{_mandir}/*/man*/* ; do iconv -f latin1 -t utf8 $file -o $file.new touch -c -r $file $file.new mv -f $file.new $file done dpkg- prefixed executables are still there. Regarding th euse of dpkg, my investigations show that, after doing touch status mkdir updates touch available mkdir info dpkg is ready to install files, with --force-bad-path since the executables renamed/not installed are not found. This seems a bit dangerous to me. Maybe we could add an empty /etc/dpkg.conf with instdir=/var/lib/dpkg_installation to avoid clobbering the rpm managed filesystem? If we go down that way, maybe also we could ship a wrapper script that sets a PATH within /var/lib/dpkg_installation and also sets LD_LIBRARY_PATH to be able to install and run packages installed through dpkg. Maybe it shouldn't be done since it is too dangerous and debian packages pre/post scripts may harm the fedora installation? Ralf, do you use dpkg to install dpkg package on a fedora? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review