[Bug 457210] Review Request: dpkg - Package maintenance system for Debian Linux

[bugzilla at redhat.com]

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 at free.fr>  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.