Bug 353271 - apt chokes on multilib Obsoletes hack
apt chokes on multilib Obsoletes hack
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: apt (Show other bugs)
7
All Linux
high Severity medium
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
https://www.redhat.com/archives/fedor...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-25 17:05 EDT by Kevin Kofler
Modified: 2007-12-06 15:51 EST (History)
2 users (show)

See Also:
Fixed In Version: 0.5.15lorg3.93-4.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-06 15:51:28 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)
Unsplit version (378 bytes, text/plain)
2007-10-26 05:36 EDT, Kevin Kofler
no flags Details
Split version with the problematic Obsoletes (559 bytes, text/plain)
2007-10-26 05:37 EDT, Kevin Kofler
no flags Details

  None (edit)
Description Kevin Kofler 2007-10-25 17:05:00 EDT
Description of problem:
This trick:
https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02171.html
is confusing APT-RPM (even on non-multilib systems), at least the version in 
F7.

I just tested this hack (on an i686 system) with a dummy package: I have 
installed a package called multilib-obsoletes-test Version: 1, Release: 1, 
then put 1-2 into a test repo (created just for this purpose), with a -libs 
subpackage which obsoletes multilib-obsoletes-test < 1-2. This confuses 
apt-get dist-upgrade, which reacts the following way:
The following packages have been kept back
   multilib-obsoletes-test (1-1 => 1-2)
In other words, it gets confused by the hack, and it won't update the package 
at all! (Synaptic reacts the same way.)

Doing apt-get install multilib-obsoletes-test or apt-get install 
multilib-obsoletes-test-libs by hand will do the right thing (the former of 
course only if multilib-obsoletes-test-1-2 Requires: 
multilib-obsoletes-test-libs, otherwise the libs package won't be pulled in), 
but the dist-upgrade should work.

Version-Release number of selected component (if applicable):
apt-0.5.15lorg3.2-12.fc7

How reproducible:
Always

Steps to Reproduce:
1. Create and install multilib-obsoletes-test-1-1
2. Create multilib-obsoletes-test-1-2 and multilib-obsoletes-test-libs-1-2 
where multilib-obsoletes-test-libs-1-2 Obsoletes: multilib-obsoletes-test < 
1-2 and multilib-obsoletes-test-1-2 Requires: multilib-obsoletes-test-libs.
3. Put those into a testing repo.
4. Enter the repo into /etc/apt/sources.list.
5. apt-get update
6. apt-get dist-upgrade
  
Actual results:
The following packages have been kept back
   multilib-obsoletes-test (1-1 => 1-2)

Expected results:
The following packages will be upgraded
   multilib-obsoletes-test (1-1 => 1-2)
The following NEW packages will be installed:
   multilib-obsoletes-test-libs (1-2)

Additional info:
See the mailing list thread.
Comment 1 Panu Matilainen 2007-10-26 05:30:02 EDT
Care to provide the specs for those test-packages? An existing, easily
reproducable test-case is always nicer than having to invent one :)

As for the bug itself, I'll have a look. Most likely it's a corner case that apt
doesn't even try to handle due to such a construct probably not making any sense
at all in Debian...
Comment 2 Kevin Kofler 2007-10-26 05:36:43 EDT
Created attachment 238711 [details]
Unsplit version
Comment 3 Kevin Kofler 2007-10-26 05:37:34 EDT
Created attachment 238721 [details]
Split version with the problematic Obsoletes
Comment 4 Kevin Kofler 2007-11-03 16:44:17 EDT
Any progress on this? Panu, can you reproduce the problem with those specs?
Comment 5 Panu Matilainen 2007-11-05 01:27:26 EST
I haven't had a chance to look at this at all yet.
Comment 6 Panu Matilainen 2007-11-16 02:41:40 EST
Heh, this appears to trigger some silly off-by-one type issue somewhere. I can
reproduce your test case easily enough:
[root@localhost cmdline]# ./apt-get dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Done
The following packages have been kept back
   multilib-obsoletes-test (1-1 => 1-2)
   multilib-obsoletes-test.32bit (1-1 => 1-2)

But bumping the split package release to 3 (and no other changes), something I
happened to test accidentally:
[root@localhost cmdline]# ./apt-get dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Done
The following packages will be upgraded
   multilib-obsoletes-test (1-1 => 1-3)
   multilib-obsoletes-test.32bit (1-1 => 1-3)
The following NEW packages will be installed:
   multilib-obsoletes-test-libs (1-3)

Now off to figure what the heck's going on... :)
Comment 7 Panu Matilainen 2007-11-16 05:29:43 EST
Some hackery applied to rawhide apt, building atm (apt-0.5.15lorg3.93-3.fc9).
Seems to work for me now both on multilib and non-multilib case, and doesn't
seem to break horribly for anything else either but knock wood, the apt upgrade
algorithm is .. um .. "interesting".

I'd appreciate if you can test it in real world situations, this kludgery has
only been tested in lab conditions with the provided multilib-obsoletes-test specs.
Comment 8 Fedora Update System 2007-11-21 22:30:57 EST
apt-0.5.15lorg3.93-4.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update apt'
Comment 9 Fedora Update System 2007-12-06 15:51:25 EST
apt-0.5.15lorg3.93-4.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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