[Aptitude-devel] Unable to compile aptitude from git [solved]
berenger.morel at neutralite.org
berenger.morel at neutralite.org
Thu Oct 31 10:09:47 GMT 2013
Le 31.10.2013 04:12, Axel Beckert a écrit :
> trying to answer what I know. The remainder is probably better
> answered by Daniel Hartwig or someone else with a better overview
> Aptitude's code than me.
> berenger.morel at neutralite.org wrote:
>> > As for every other package, ensure that you have a deb-src line in
>> > your sources.list matching the deb line the package is coming from
>> > and execute:
>> > apt-get build-dep aptitude
>> > It should install all needed packages to build the package from
>> > source.
>> To be honest, I did not did it, for a more or less valid reason:
>> there were a lot of things needed, that I am not able to see why
>> they should be needed.
> Unfortunately that's not a valid reason. ;-)
No, but I learn more by fixing errors than by following procedures
without understanding requirements. It have always been a problem when I
was at school :D
>> There were also things that aptitude does not seems to depends,
> It's very common that there is more software needed to build a
> than to use it, especially if a program has a test-suite, because
> there are usually additional programs needed to run the tests.
> common reason is building documentation from sources.
Should not those requirements be only suggestions, since the software
is not effectively depending (depends) on it nor have additional
features provided by (recommended) ?
>> when I look into what aptitude says about aptitude's dependencies,
>> like python-dev
> It's libboost-python-dev which pulls in python-dev.
> I must admit I wasn't able to find the reason for this
> build-dependency immediately and the versioning control history
> doesn't reach as far back as when this was added. So I tried to build
> aptitude without this build-dependency to see where it fails... Did
> that with the current version of Aptitude in Debian Unstable.
> It indeed builds without the libboost-python-dev build-dependency and
> even the resulting file lists dependencies of the resulting binary
> package show no relevant differences.
> I suspect this is a relict from
> the times where also an Aptitude GUI was built.
You mean aptitude-gtk, which was there some months ago? I did not even
noticed it has been removed from debian's repo. But I have tried it, and
since I always pay attention to dependencies when installing something,
I do not think that it had a python dependency (I usually do not like a
lot python softwares, they pull in lot of dependencies and sometimes I
do not understand why. So I avoid them. I try to acquire the best
knowledge possible about my system, so I try to avoid things I do not
understand when I can choose. It's a game for me, no real reason.).
Reading dependencies at packages.debian.org says the same.
But I guess that aptitude have a long history of "tried and stopped".
Just browsing the tree taught me that there is/were a qt port, too.
>> (and I just checked anew, even in aptitude's dependencies
>> there are no python dependency). But I do not know how build-dep
>> works in it's internals, so I may be wrong anyway.
> Basically, the Build-Depends in debian/control lists all packages
> _necessary_ to build the package properly -- except those which are
> already a dependency of the package build-essential or of priority
Oh, so it is a list in the source package. Good to know, thanks for the
>> I already did some installation the same way as I did, and
>> everything was fine.
> Sometimes some build-dependencies are optional, but if they're
> missing, the built packages has not all features it should have. This
> often affects stuff like GNOME or KDE support or supporting one or
> more image formats.
Indeed. I rarely install recommended packages. Most of the time, I do
not need the secondary features of the softwares.
>> At least, I had some dependency errors, but was able to fix them
>> easily by reading the output.
> Actually you don't have to do that. The package maintainer already
> that and wrote the result into the above mentioned Build-Depends
Yes, but since I did not used aptitude build-dep to build them, and
since are not always a readme file explicitly giving dependencies, it's
how I did. Plus, it can sometimes reveal errors in the package (due to a
change not actualized, for example, maybe like the python-dev here).
>> I just installed the aptitude build-dep stuff, and have exactly the
>> same result, still against the git repo.
> I can confirm that though. Looks like some Boost incompatibility with
> the current boost version. I suspect the fix of 0.6.8.2-1.2 is
> in Git.
That was what I thought, but I am surprised that the problems would
come in the ./configure step. If it was at compile time, I would have
fixed myself, but I do not know at all autotools.
I wonder, is there is any reason to stick with the boost framework for
smart pointers ( since the error seems to be related to shared_ptr )
instead of using the standards one?
I just tried with the version in testing ( version 0.6.8.2-1.2, I used
the command "&apt-get -b source aptitude -t testing" ) and the problem
> Daniel, can you answer that one more precisely?
No need, finally, I have found the error myself:
I should have thought about it sooner, clang is not the default
compiler in Debian... sadly, since it's way faster. I guess this might
still be considered a bug, right?
Note that I am still compiling, so maybe I'll have compilation errors,
but those would be a different issue.
>> > As this is a aptitude specific question I would suggest following
>> > up on aptitude-devel at lists.alioth.debian.org as they can probably
>> > help better with more specific problems than deity@ can.
>> Sorry for that, I did not found it on the wiki page
> (JFTR: That's no wiki page.)
> The page is maintained by the Debian List Masters and includes only
> lists on lists.debian.org -- Aptitude's mailing list is a list which
> belongs to the project Aptitude on Alioth (alioth.debian.org,
> instance of a SourceForge-alike system), and Alioth's lists
> independent of those lists hosted on lists.debian.org. (Yes, this may
> be not obvious. Just explaining.)
> Regards, Axel
Ok. Thanks for that info. I thought aptitude was a debian's project,
given the name and the role.
More information about the Aptitude-devel