[Lucid][SRU][PATCH 1/1] UBUNTU: Remove conflicts statements for compat-wireless meta packages

[Tim Gardner]

On 12/02/2010 10:11 AM, Stefan Bader wrote:
> On 12/02/2010 05:45 PM, Leann Ogasawara wrote:
>> On Thu, 2010-12-02 at 14:55 +0100, Stefan Bader wrote:
>>> On 12/02/2010 03:11 AM, Leann Ogasawara wrote:
>>>> BugLink: http://bugs.launchpad.net/bugs/683944
>>>>
>>>> SRU Justification:
>>>>
>>>> Examining the Lucid compat-wireless LBM meta packages it appears the
>>>> 'Conflicts:' statements in each of the debian/control.d flavours is
>>>> unnecessary. The LBM packages themselves already have the appropriate
>>>> 'Conflicts:' statements. Furthermore, they are coded in only one
>>>> location in each of the LBM packages
>>>> (debian/control.d/flavour-control.stub) which is much simpler to track
>>>> and update vs multiple separate files in each of the meta package
>>>> flavours.
>>>>
>>>> Impact: The package resolver should do the right thing given each
>>>> compat-wireless-2.6.3X package has correct 'Conflicts"' statements in
>>>> its dependencies, thus there should be no impact.
>>>>
>>>> Test Case: Test installing the LBM compat-wireless meta packages and
>>>> confirm multiple versions of the compat-wireless package are not
>>>> installable at the same time.
>>>>
>>> Apart from it seeming in various states of being commented out, when testing,
>>> was there a difference in that the meta package was started to install and when
>>> pulling the real binary package, failed? Or just as before immediately fails
>>> when trying to install a conflicting meta package?
>>
>> In my testing I saw the following:
>>
>> Selecting previously deselected package
>> linux-backports-modules-wireless-2.6.35-lucid-generic.
>> (Reading database ... 218140 files and directories currently installed.)
>> Unpacking linux-backports-modules-wireless-2.6.35-lucid-generic (from
>> linux-backports-modules-wireless-2.6.35-lucid-generic_2.6.32.26.29_amd64.deb) ...
>> Selecting previously deselected package
>> linux-backports-modules-compat-wireless-2.6.35-2.6.32-26-generic.
>> dpkg:
>> regarding .../linux-backports-modules-compat-wireless-2.6.35-2.6.32-26-generic_2.6.32-26.25_amd64.deb containing linux-backports-modules-compat-wireless-2.6.35-2.6.32-26-generic:
>>   linux-backports-modules-compat-wireless-2.6.35-2.6.32-26-generic
>> conflicts with
>> linux-backports-modules-compat-wireless-2.6.36-2.6.32-26-generic
>>    linux-backports-modules-compat-wireless-2.6.36-2.6.32-26-generic
>> (version 2.6.32-26.25) is present and installed.
>> dpkg: error
>> processing ../linux-backports-modules-compat-wireless-2.6.35-2.6.32-26-generic_2.6.32-26.25_amd64.deb (--install):
>>   conflicting packages - not installing
>> linux-backports-modules-compat-wireless-2.6.35-2.6.32-26-generic
>> dpkg: dependency problems prevent configuration of
>> linux-backports-modules-wireless-2.6.35-lucid-generic:
>>   linux-backports-modules-wireless-2.6.35-lucid-generic depends on
>> linux-backports-modules-compat-wireless-2.6.35-2.6.32-26-generic;
>> however:
>>    Package
>> linux-backports-modules-compat-wireless-2.6.35-2.6.32-26-generic is not
>> installed.
>> dpkg: error processing
>> linux-backports-modules-wireless-2.6.35-lucid-generic (--install):
>>   dependency problems - leaving unconfigured
>> Errors were encountered while processing:
>>   ../linux-backports-modules-compat-wireless-2.6.35-2.6.32-26-generic_2.6.32-26.25_amd64.deb
>>   linux-backports-modules-wireless-2.6.35-lucid-generic
>>
>
> Ok, so if I read that correctly the effect would be that the meta package gets
> installed but is left unconfigured because the binary package conflicts. While,
> I think, with the conflicts in the meta packages too, the meta package would
> reject being installed.
> So thinking further, maybe this would allow de-installing the binary package,
> then installing the meta package, but leaving any previous meta package alone?
> Which probably could be an issue.
> Which we already should have on Maverick then. Just that maybe not many people
> really do this.
>
> Stefan

I think the effect is that, given the conflicts, neither the meta 
package or its dependencies could be installed. Furthermore, I do not 
think you can remove a binary package upon which the meta package is 
dependent without also removing the meta package.

rtg
-- 
Tim Gardner tim.gardner at canonical.com