Bug 979378
An irritating technicality: * There's no "version-not-equal" relation in dependencies. * So I "emulated" this with two "foo < version" and "foo > version" relations. * Any problems with this? (aside from aesthetics) Re-tested the failure in different scenario:
* Prepared test with dpkg-devel.noarch (<= 1.15*) installed
- Which pulls dpkg (<= 1.15*)
* Then "dnf update":
- Pulls new dpkg-devel.<ARCH> as an update (interesting...)
- Upgrade OK
- Of course it doesn't know new dpkg-devel.<ARCH> is completely
different from old dpkg-devel.noarch, but it's harmless for now.
* Then try to "dnf install dh-make" (new one 0.61-1.fc18):
- Pulls new dpkg-dev (1.16.10-4.fc18).
- Which pulls new dpkg-perl.
- Which fails because the following two files belong to old (<= 1.15*) dpkg:
/usr/share/perl5/vendor_perl/Dpkg.pm
/usr/share/perl5/vendor_perl/Dpkg/Gettext.pm
So passing through intermediate upgrade to dpkg-devel=1.16.10-4.fc18
solve some of the problems (dpkg-dev conflict with old dpkg-devel),
but not all -- there's still a conflict of dpkg-perl with old dpkg.
Hi, give us the diff of the spec , to analyze please Created attachment 766737 [details]
Patch to .spec file for fixing dpkg upgrade from <= 1.15 to >= 1.16
+# Obsolete the old dpkg-devel.noarch (replaced by dpkg-dev)
+Obsoletes: dpkg-devel < 1.16
this one, ok !
>> - Which pulls new dpkg-perl.
and fails because conflicts with old dpkg
So dpkg-perl needs also Obsoletes dpkg < 1.16
or even better
I Drop Requirement dpkg of dpkg-perl (seems to me correct at the time ...)
but that requirement solve this situation, so what do you think ?
dpkg-perl requires dpkg = %{version}-%{release}
instead
+# We don't depend on dpkg, but we don't allow different version of it
+Conflicts: dpkg < %{version}-%{release}
+Conflicts: dpkg > %{version}-%{release}
+# We don't depend on dpkg-devel, but we don't allow different version of it
+Conflicts: dpkg-devel < %{version}-%{release}
+Conflicts: dpkg-devel > %{version}-%{release}
I've started looking deeper at the dependency relationships
and decided I'll compare a bit more the Debian/Fedora packages.
Here are some preliminary findings:
* Should be moved from dpkg to dpkg-dev:
- dpkg-mergechangelogs and its man-pages
- dpkg-buildflags and its man-pages
* /etc/dpkg.cfg should be in /etc/dpkg/dpkg.cfg
* There is a bunch of man pages owned both by dpkg and dpkg-dev
(in many languages):
dpkg-architecture.1.gz
dpkg-buildflags.1.gz
dpkg-buildpackage.1.gz
dpkg-checkbuilddeps.1.gz
dpkg-distaddfile.1.gz
dpkg-genchanges.1.gz
dpkg-gencontrol.1.gz
dpkg-gensymbols.1.gz
dpkg-mergechangelogs.1.gz
dpkg-name.1.gz
dpkg-parsechangelog.1.gz
dpkg-scanpackages.1.gz
dpkg-scansources.1.gz
dpkg-shlibdeps.1.gz
dpkg-source.1.gz
dpkg-vendor.1.gz
* The dpkg-dev.mo translation files:
- For some unknown reason, Debian maintain them in libdpkg-perl
- In Fedora we assigned them to dpkg-dev
- Although our assignment look more logical, this affect package dependencies.
- As an example /usr/libexec/dpkg/parsechangelog/debian calls
textdomain("dpkg-dev"). In Debian, both belog to libdpkg-perl.
In Fedora, the files are in two separate packages.
This is for now. Later, I'll try to send patches for some of these problems.
(In reply to Oron Peled from comment #6) > I've started looking deeper at the dependency relationships > and decided I'll compare a bit more the Debian/Fedora packages. > > Here are some preliminary findings: > * Should be moved from dpkg to dpkg-dev: > - dpkg-mergechangelogs and its man-pages > - dpkg-buildflags and its man-pages no problem I will do it right now , > > * /etc/dpkg.cfg should be in /etc/dpkg/dpkg.cfg hum ok, see it later > * There is a bunch of man pages owned both by dpkg and dpkg-dev > (in many languages): > dpkg-architecture.1.gz > dpkg-buildflags.1.gz > dpkg-buildpackage.1.gz > dpkg-checkbuilddeps.1.gz > dpkg-distaddfile.1.gz > dpkg-genchanges.1.gz > dpkg-gencontrol.1.gz > dpkg-gensymbols.1.gz > dpkg-mergechangelogs.1.gz > dpkg-name.1.gz > dpkg-parsechangelog.1.gz > dpkg-scanpackages.1.gz > dpkg-scansources.1.gz > dpkg-shlibdeps.1.gz > dpkg-source.1.gz > dpkg-vendor.1.gz > this is obvious bug in spec grep dpkg-architecture dpkg.spec %{_mandir}/man1/dpkg-architecture.1.gz %{_mandir}/*/man1/dpkg-architecture.1.gz %{_bindir}/dpkg-architecture %{_mandir}/man1/dpkg-architecture.1.gz %{_mandir}/*/man1/dpkg-architecture.1.gz man are duplicated , and should be just in correspondent package , I will commit the fix right now in master. Created attachment 766926 [details]
This move dpkg-buildflags and dpkg-mergechangelogs form dpkg to dpkg-dev
* Move binaries and their man-pages from dpkg to dpkg-dev
Created attachment 766927 [details]
remove multiple ownership of some manual pages
* These all belong to dpkg-dev. So remove them from dpkg
Created attachment 766929 [details]
move dpkg.cfg from /etc to /etc/dpkg
Looking at upstream code -- all configuration files are under /etc/dpkg:
* In lib/dpkg/options.c (line 197):
m_asprintf(&file, "%s/%s.cfg", CONFIGDIR, prog);
* The CONFIGDIR is passed from Makefile.am:
-DCONFIGDIR=\"$(pkgconfdir)\"
* In Makefile.am pkgconfdir is set:
pkgconfdir = $(sysconfdir)/@PACKAGE@
Created attachment 766930 [details]
fix some pkgdatadir, pkgconfdir file locations
* Define pkgdatadir for consistency (just like upstream name in Makefile.am)
* Added missing shlibs.{default,override} (from debian/dpkg-dev.install)
* Move %{pkgdatadir}/abitable from dpkg-dev to dpkg (from debian/dpkg.install)
* Grab all %{pkgdatadir}/*.mk into dpkg-dev (from debian/dpkg-dev.install)
* Thanks for the quick update. * Attached two more patches. * If you have time now, we can continue this on IRC (#fedora-devel [oron]) (In reply to Oron Peled from comment #13) > * If you have time now, we can continue this on IRC (#fedora-devel [oron]) Thanks , Now I going out, now , sorry . what do you think ? about : dpkg-perl requires dpkg = %{version}-%{release} , instead +# We don't depend on dpkg, but we don't allow different version of it +Conflicts: dpkg < %{version}-%{release} +Conflicts: dpkg > %{version}-%{release} +# We don't depend on dpkg-devel, but we don't allow different version of it +Conflicts: dpkg-devel < %{version}-%{release} +Conflicts: dpkg-devel > %{version}-%{release} seems to me more clean . Created attachment 766936 [details]
move "dpkg-dev.mo" files to dpkg-perl
* In upstream they also belong to libdpkg-perl and not dpkg-dev
* In dpkg-perl, they are used by /usr/libexec/dpkg/parsechangelog/debian:
textdomain("dpkg-dev");
Created attachment 766937 [details]
minor fix to dpkg-perl ownerships
* Some directories were not owned (e.g: /usr/share/perl5/.../Dpkg/Compression)
* Use wildcards as in upstream debian/libdpkg-perl.install, so we don't
have similar bugs in the future.
(In reply to Sergio from comment #14) * I first wanted to make sure we have equivalent packages to Debian's (in terms of contained files). Otherwise, it's hard to compare dependencies. * Checking now (after applying the patches in comment #15 and #16): - Upstream libdpkg-perl "Depends" on dpkg (specific version range) - Also, I've found specific perl modules that call dpkg commands: /usr/share/perl5/vendor_perl/Dpkg/Arch.pm run "dpkg --print-architecture" /usr/share/perl5/vendor_perl/Dpkg/Path.pm run "dpkg-query" /usr/share/perl5/vendor_perl/Dpkg/Source/Package.pm run "dpkg-source" - So not having "Requires: dpkg" for dpkg-perl was our mistake in the first place. - I also agree that we can have stricter version requirements than upstream. - So let's do what you suggested and add to dpkg-perl: Requires: dpkg = %{version}-%{release} - Since "dpkg-dev" already requires "dpkg-perl = %{version}-%{release}, that means we don't need my first set of "Conflicts" (dpkg <> ...) Because dpkg-dev pulls same version of dpkg-perl and that will pull same version of dpkg. * If you can review and commit: - First, my comment #15 and comment #16 (less conflicts for my git private branch). - Than your proposed "Requires:" for dpkg-perl - I'll re-sync and we can do final checks what to do with the other suggested Conflicts (dpkg-devel <> ...) all 4 patches pushed more # Obsolete the old dpkg-devel.noarch (replaced by dpkg-dev) Obsoletes: dpkg-devel < 1.16
more add to dpkg-perl: Requires: dpkg = %{version}-%{release}
http://pkgs.fedoraproject.org/cgit/dpkg.git/patch/?id=6d0630eecf685c5fb9eb786ac48c0a10cc358ad3
dpkg-1.16.10-5.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/dpkg-1.16.10-5.fc19 dpkg-1.16.10-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/dpkg-1.16.10-5.fc18 Created attachment 766996 [details]
add patched /etc/logrotate.d/dpkg
Created attachment 766997 [details]
cleanup spec: s/$RPM_BUILD_ROOT/%{buildroot}/g
There was mixed use of $RPM_BUILD_ROOT and %{rpmbuild}
Created attachment 766998 [details]
added some new %doc and debian/copyright
* debian/copyright is up-to-date and include more info than old COPYING file
* Added other, missing docs
Created attachment 766999 [details]
minor rpmlint cleanups
(In reply to comment #19 and #20 -- bodhi updates) * Oops, you are quick. I thought you'll just commit to git and we'll have a final round of cleanups before pushing to bodhi. * Your version looks OK, but: - Maybe you want to push the last fixes before you push the new package. The logrotate may be important. (comments #21, #22, #23, #24) - If not, the fixes can wait in git for some other opportunity. (In reply to Oron Peled from comment #25) > (In reply to comment #19 and #20 -- bodhi updates) > > * Oops, you are quick. I thought you'll just commit to git and we'll > have a final round of cleanups before pushing to bodhi. > > * Your version looks OK, but: > - Maybe you want to push the last fixes before you push the new package. > The logrotate may be important. (comments #21, #22, #23, #24) > - If not, the fixes can wait in git for some other opportunity. Hi, Thanks for the patches, I will include yours last 4 patches (all) , in git . Should I bump a release or we have more things to fix ? Package dpkg-1.16.10-5.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dpkg-1.16.10-5.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11999/dpkg-1.16.10-5.fc18 then log in and leave karma (feedback). dpkg-1.16.10-6.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/dpkg-1.16.10-6.fc19 dpkg-1.16.10-6.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/dpkg-1.16.10-6.fc18 Tested 1.16.10-6 (both f18 and f19) -- all well. dpkg-1.16.10-6.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. dpkg-1.16.10-6.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. |
Steps to Reproduce (f18): 1. Install dpkg-devel.noarch (1.15*) 2. Try to install dpkg-dev (1.16*) Actual results: Yum/dnf check transaction, and RPM fails with conflicting files Expected results: 1. dpkg-dev pulls dpkg-perl 2. dpkg-devel.noarch removed 3. If dpkg < 1.15 is present, it is upgraded to dpkg >= 1.16* Additional info: * Prepared and tested updated spec. SPEC URL: http://oron.fedorapeople.org/deb-package/dpkg.spec * The .spec changes are commented and with description in %changelog * Although the primary fix is for f18, I think its important to fix on all releases (e.g: it may fail people who try to upgrade f18 -> f19, etc.)