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

Bug#547724: apt-get build-dep $PACKAGE doesn't handle build-dependencies with architecture wildcards



* Julian Andres Klode | 2010-06-27 21:14:12 [+0200]:

>Well, you used malloc() instead of new. And it should be a bzr merge
>directive against the debian-experimental-ma branch:
>   http://bzr.debian.org/apt/apt/debian-experimental-ma/
>
>> On the other hand if you don't want it, don't take it, I did my best to
>> keep things simple :)
>Yes, but apparently (as written below) the inventors of the wildcards
>system did not.
Okay, so from what I read below you are happy with the solution you have
now and you don't want to rebase the patch or do anything?

>Oh, I did not know that this works. I thought it would be a sane design,
>but apparently it is not (a sane design would be any-armel matching
>armel, and any-arm matching arm [that's what I thought and
>implemented]). Things could be so easy if they were done the way I want
>them to be... (and you would know that you are on linux if no '-' is in
>your architecture name).
Okay. According to the comments in dpkg this may change. And other
kernels may come along.

>The debian-experimental-ma branch contains support this way for all
>currently supported architectures; that is, those currently listed in
>dpkg's triplettable (using a few hand-coded overwrites for non-standard
>stuff such as armel, powerpcspe and lpia) [although we can drop lpia, as
>no one seems to have it anymore].
okay.

>> So instead of implementing all this informations and rules from scratch
>> (and maybe introducing some bugs) I just followed existing code and used
>> data which is also used by dpkg.
>OK. I guess it might make sense to read the information on run-time, to
>support all systems as soon as they are added to dpkg, without having to
>rebuild APT. The information could be put in debSystem, so it will only
>be read once. 
>
>Then change CompleteArch() in apt-pkg/deb/deblistparser.cc to return
>values based on this information.

Well yes. lintian needs also to know all the valid architectures to able
to create the "unknown architecture" warning. They choose to create a
table based on dpkg's info since there are probably more lintian updates
than new architectures.

Sebastian



Reply to: