Bug 353271 - apt chokes on multilib Obsoletes hack
Summary: apt chokes on multilib Obsoletes hack
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: apt
Version: 7
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Axel Thimm
QA Contact: Fedora Extras Quality Assurance
URL: https://www.redhat.com/archives/fedor...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-25 21:05 UTC by Kevin Kofler
Modified: 2007-12-06 20:51 UTC (History)
2 users (show)

Fixed In Version: 0.5.15lorg3.93-4.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-12-06 20:51:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Unsplit version (378 bytes, text/plain)
2007-10-26 09:36 UTC, Kevin Kofler
no flags Details
Split version with the problematic Obsoletes (559 bytes, text/plain)
2007-10-26 09:37 UTC, Kevin Kofler
no flags Details

Description Kevin Kofler 2007-10-25 21:05:00 UTC
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 09:30:02 UTC
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 09:36:43 UTC
Created attachment 238711 [details]
Unsplit version

Comment 3 Kevin Kofler 2007-10-26 09:37:34 UTC
Created attachment 238721 [details]
Split version with the problematic Obsoletes

Comment 4 Kevin Kofler 2007-11-03 20:44:17 UTC
Any progress on this? Panu, can you reproduce the problem with those specs?

Comment 5 Panu Matilainen 2007-11-05 06:27:26 UTC
I haven't had a chance to look at this at all yet.

Comment 6 Panu Matilainen 2007-11-16 07:41:40 UTC
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 10:29:43 UTC
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-22 03:30:57 UTC
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 20:51:25 UTC
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.