Bug#687255: apt_preferences(5) support for pinning by architecture
On 12 September 2012 19:00, Julian Andres Klode <jak@debian.org> wrote:
> On Tue, Sep 11, 2012 at 04:13:15PM +0800, Daniel Hartwig wrote:
>> I see where the support for this is in versionmatch.cc and the above
>> seems to not work because PackageFile::Architecture is never
>> populated. Actually, python-apt docs say this is normal:
>
> You can only have those for Debian-style repositories with
> dists/, you can not have this for flat repositories.
Isn't that limitation also true of other details, such as component
(“c=main”)? I don't see why not to include the architecture when it
is available and unambiguous.
> It does not work, probably because APT tries to pin aptitude:i386 to
> a version with architecture: amd64, which does not exist. I'd go
> with EXPRESSION:ARCHITECTURE pinning, like aptitude:amd64 or *:amd64,
> or /regex/:amd64. But we don't appear to have implemented *:amd64
> correctly yet (with the same semantics as *, it is not considered
> more generic than name:amd64). I don't know whether this is possible
> though.
True. I suppose this could be handled either way (both?) by
considering “*:ARCH” more general as you suggest, or by having
“b=ARCH” ignored for packages on other archs.
Although I do not have much knowledge of versionmatch.cc it appears
your suggestion is much easier to implement and also does not adjust
the semantics of release pinning so much.
Regards
Reply to: