[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#712116: DPkg::Pre-Install-Pkgs should receive multiarch-qualified package names



On Mon, Jun 17, 2013 at 11:01 AM, Geoffrey Thomas <geofft@mit.edu> wrote:
> On Thu, 13 Jun 2013, Anders Kaseorg wrote:
>
>> The current input format for DPkg::Pre-Install-Pkgs hooks makes it
>> impossible to tell which architecture of a multiarch package is being
>> removed.  For example, removing libbz2-1.0:amd64 and libbz2-1.0:i386
>> results in this input:
>>
>> libbz2-1.0 1.0.6-4 > - **REMOVE**
>> libbz2-1.0 1.0.6-4 > - **REMOVE**
>>
>> Can we change the format to arch-qualify the package names as
>> ${binary:Package} does?
>
>
> Attached is a patch to add a new v3 mode for input to Pre-Install-Pkgs, and
> extend SendV2Pkgs to insert the architecture immediately after the name of
> the package. I've tested this locally and this seems to work fine for
> installing and removing native-arch, arch-all, and non-native-arch packages.

Thanks for reporting & the patch to you both!


> (The native arch, not "all", seems to get displayed for arch-all packages,
> which seems acceptable but a little confusing.)

That's a multiarch thing as arch:all packages are treated like arch:native
packages. Try calling Arch() on a version iterator instead, it will give
you "all".

Its hinting at a problem though: The architecture really belongs to the
version, not to the package as a package can change the architecture
(from "all" to "native" and back – I am not talking about cross-grades,
 these are different, at least currently) which will only be visible on
the version level.

So the attached patch adds the architecture behind every version number it
prints (and while at it, it also adds the MultiArch flag), doesn't break
the ABI (the method is protected, so in theory someone could use it) and
adds a small testcase.

It would be cool if you could test this through and/or comment on if this is
enough for your needs. I am also cc'ing the apt-listbugs maintainers as it
looks like it pins the wrong package if its using v2 currently and I am also
not really sure if the pin-logic shouldn't be changed drastically as a bug
usually effects all architectures and not just one, but my ruby knowledge
is non-existent, so I could be completely wrong on this.


Best regards

David Kalnischkies

Attachment: 0001-Version-3-for-DPkg-Pre-Install-Pkgs-with-MultiArch-i.patch
Description: Binary data


Reply to: