Bug#547724: apt-get build-dep $PACKAGE doesn't handle build-dependencies with architecture wildcards
On So, 2010-06-27 at 19:29 +0200, Sebastian Andrzej Siewior wrote:
> * Julian Andres Klode | 2010-06-26 20:31:34 [+0200]:
>
> >Your patch does not make much sense. APT is written in C++, but you are
> >writing raw C code (and use different function naming style).
> The function's name can be renmaned to what you want. Yes it is pure C
> and I kept it simple and cloned the perl routine as close as possible. I
> wasn't aware that it is such a big deal. That piece of C isn't visible
> from the outside and I did not introduced a warning or something like
> that. The exported C++ can still be used the same way. The difference
> between C++ is using libc's C-API right? Other files, like
> apt-pkg/init.cc, also include C API via cstdlib. What exactly is the
> problem?
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.
>
> >Furthermore, I think it should be much easier to support this than you
> >do in your patch. We just need to do replace 'any' in the architecture
> >wildcard by '*' and check if it matches the current arch or the current
> >arch prefixed by 'linux-' by calling fnmatch().
> This will work for the linux-any but how do you know that you are linux
> and not kfreebsd? For these reasons you need the debian and cpu
> tripplet table so you can look it up. This is also requiered in order to
> correctly match any-arm against armel or any-i386 against lpia.
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).
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].
> 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.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: