Bug#547724: apt-get build-dep $PACKAGE doesn't handle build-dependencies with architecture wildcards
On Mo, 2010-06-28 at 22:38 +0200, Sebastian Andrzej Siewior wrote:
> * 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?
No, but we can implement this in the terms of the thing I already wrote,
utilizing standard matching stuff. The only thing we need to do is to
map the Debian architecture to the correct <kernel>-<cpu> combination,
this can be done by parsing triplettable and loading all non-variable
entries there (such as armel) (or replacing <cpu> with * and matching it
against the current architecture) and returning the value of the first
column, beginning after the first '-'
>
> >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.
Lintian is a bit different anyway, as it needs more information than
APT. We don't need to know if an architecture is valid, the only thing
we need to know is whether it matches the current one. BTW, we would not
need a new APT release for a new architecture, a binNMU would suffice
when using your idea.
The current solution is:
static string CompleteArch(std::string& arch) {
if (arch == "armel") return "linux-arm";
if (arch == "lpia") return "linux-i386";
if (arch == "powerpcspe") return "linux-powerpc";
if (arch == "uclibc-linux-armel") return "linux-arm";
if (arch == "uclinux-armel") return "uclinux-arm";
return (arch.find("-") != string::npos) ? arch : "linux-" + arch;
}
and it works fairly well. Any other solution should have a bit more
people looking at it due to the increased complexity.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: