Am 02.12.2009 um 19:46 schrieb Daniel Macks:

> On Wed, Dec 02, 2009 at 06:39:11PM +0100, Max Horn wrote:
>>
[...]
>>
>> Exactly. I am unhappy whenever a package forces me to uninstall  
>> ccache-
>> default, even if it is only temporary and and it gets reinstalled
>> later on automatically: It affects all my concurrent build  
>> activities,
>> which is negative. Also, I wonder what happens if I try to "fink
>> build" two packages *in parallel* (i.e. in different terminals) that
>> both conflict with ccache-default , esp. if one finishes earlier than
>> the other ?
>
> The first one's attempt to reinstall (i.e., while the second one is
> still building) will fail because a build_lock_ still exists, not just
> a fink "remove this before start the process" action. The whole
> purpose of the buildlock system is to make it safe to run multiple
> fink instances concurrently. Which adds to the poor user experience in
> this case because "could not reinstall after building" will cause the
> first fink process to fail.

So, do we agree that it would be nice to not "build conflict" with  
ccache?

If so, I'd be willing to investigate making it work without the  
"ccache" and "distcc" build conflicts. For starters, though, I'd like  
to know why this BuildConflict is there in the first place, so that I  
can verify whether my changes actually work. In a quick test, simply  
commenting out the BuildConflicts did not cause any particular build  
issues. The .info file also contains no comments that explain this  
build conflict...

Cheers,
Max

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to