On Wed, 21 Jan 2015 19:21:28 +0100 Michał Górny <[email protected]> wrote:
[...] > > > 1. What does || ( a b:= c:= ) mean? i.e. only some having > > > subslots. > > > > This makes sense only when in DEPEND+RDEPEND (because of the :=), so > > apply this (mostly copy/paste) for all such deps: > > for a in 'a' 'b' 'c': > > When the package is built, if 'a' is satisfied and has a := > > dep then 'a' and its subslot is added to := deps list for > > the installed package > > > > As for the meaning, it uses all of a, b and c that are available at > > buildtime and at least one of them must be present. > > for 'b' and 'c', the := dep description/meaning from pms applies. > > > > > 2. What does || ( a:= b:= ) mean when a and b can be both > > > installed? > > > > Ditto. > > A fair bit inconsistent but I guess it is the safe solution. Of > course, it is ugly for making || () behave completely different from > the original meaning when := is used inside. You add subslot, you get > completely different behavior. You remove it, you get completely > different behavior... Can you answer the same question removing ':=' ? I might have missed something but, as I see it, it is the same meaning with and without :=, and this just provides an algorithm on how to trigger the rebuilds. [...] > It is easy to write others how to do stuff without looking at the > code, isn't it? It is, indeed. But two things: 1. If portage uses crafted depstrings in its depgraph when rebuilding a package and nobody is able to give me a good reason _why_ this is needed, I really do not want to look at the code :) 2. From my experience, such input is very useful: Yes, it often annoys me and sometimes even pisses me off that some external guy comes and tells me I have to trash all that code I wrote, that costed me a lot, and even I have problems understanding it. But, in the end, more often than not, I realize that I was too much into the code and not enough into understanding and simplifying the global picture and that this external input allows me to make the code simpler, less buggy and much more maintainable. Alexis.
