Axel Thimm wrote:
I see, good cheating ;)
:o)
You will probably have a couple of false positives from code that is
not being installed.
Interesting. I'll keep that in mind.
>> I guess that if thetango cannot compute the depdency then it
probably
>> gets discarded to at least get some better ordering, but the final
>> build will still need a brute force iterative approach.
>>
> Nope. This absolutely is 100 times better than a brute force iterative
> approach. IMO of course :)
>
It's surely better, what I mean is you cannot avoid the final
iterative approach, you can only provide a better ordered package list
to start with.
For example even when you can cheat a simulated build to find perl
dependecnies, as well as many other script language depedencies, you
will not be able to detect stuff needed for BuildRequires:
%{_libdir}/libfoo.so, which as brain-daed as it looks it is sometimes
needed when packages transition for not having *-devel to having
one. I even have submitted such a package.
Isn't there also a libtool that would figure that out as well? As the
code mentions I have not implemented it yet, but I intend to do so.
But I agree, having an almost fully sorted filelist is 100x better
than a
random one.
I'm going to return to the system that I did the brute force build on
this week. It is only a 64p/128G box, and I'm going to write code that
uses a bottom-up tree algorithm to build the RPMS. I'd like to see how
much faster having the sorted list is.
How about the following addition idea: Does restating thetango on
cached results with a couple different provides take up too much time?
Probably not. In that case you could append such an incremental
thetango call after each package is built and dynamically adjust the
ordering while building getting an almost 100% correct ordering. But
maybe it is already 95% good and the final 5% will be using brute
force, so it would be not worth while to do dynamical adjustments.
Hmmm ... I haven't even considered that. I'll add that to the TODO list. :)
P.