Matt Turner schrieb:
> On Sun, Jul 1, 2012 at 4:52 PM, Thomas Sachau <to...@gentoo.org> wrote:
>> Matt Turner schrieb:
>>> I suppose that's just for ease of implementation? Not having to
>>> special-case packages that don't install binaries.
>>
>> I dont follow. Did you think about only having additional ABI flags for
>> certain cases?
> 
> Right. It seems to me that not having the ABI flags for packages like
> x11-proto/* would make more sense, but may be more work to implement.

The problem here is the following: How do you know before the
src_install phase, that a package has no ABI-specific content? And even,
if you know that, how would you define the dependency part? This would
probably become pretty complex, since it also has to support corner cases.

> 
>> Those ABI flags behave the same as other USE flags: When you change
>> them, you have to recompile the package including all the content, that
>> has been compiled previously.
>> If you want the compile for each ABI seperate, then you would have to
>> handle them more like SLOTS, but with a new syntax, with a collision
>> handler for the common content and how to handle that in the user UI. I
>> fear, that this would be way more complicated to implement in a sane
>> way, so i dont plan to go that route.
> 
> Ouch. I already think a mechanism for telling the package manager "you
> don't need to rebuild this entire package to turn on /this/ USE flag"
> is needed. For ABIs, the situation seems much more clear-cut. In fact,
> it seems rather important.

This would require a good amount of changes. Since my work with
multilib-portage started in 2009 and is still not in the PMS, also i
tried to keep it simple, i would not even try to guess an ETA for both
of your, in my eyes more complex, ideas. ;-)

I of course wont prevent you from preparing them and getting them in,
they may be nice, especially removing the need to recompile already
compiled code. Just dont underestimate the work with it.


-- 

Thomas Sachau
Gentoo Linux Developer



Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to