| 1 |
On Wed, 21 Jan 2015 19:21:28 +0100 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
[...] |
| 5 |
> > > 1. What does || ( a b:= c:= ) mean? i.e. only some having |
| 6 |
> > > subslots. |
| 7 |
> > |
| 8 |
> > This makes sense only when in DEPEND+RDEPEND (because of the :=), so |
| 9 |
> > apply this (mostly copy/paste) for all such deps: |
| 10 |
> > for a in 'a' 'b' 'c': |
| 11 |
> > When the package is built, if 'a' is satisfied and has a := |
| 12 |
> > dep then 'a' and its subslot is added to := deps list for |
| 13 |
> > the installed package |
| 14 |
> > |
| 15 |
> > As for the meaning, it uses all of a, b and c that are available at |
| 16 |
> > buildtime and at least one of them must be present. |
| 17 |
> > for 'b' and 'c', the := dep description/meaning from pms applies. |
| 18 |
> > |
| 19 |
> > > 2. What does || ( a:= b:= ) mean when a and b can be both |
| 20 |
> > > installed? |
| 21 |
> > |
| 22 |
> > Ditto. |
| 23 |
> |
| 24 |
> A fair bit inconsistent but I guess it is the safe solution. Of |
| 25 |
> course, it is ugly for making || () behave completely different from |
| 26 |
> the original meaning when := is used inside. You add subslot, you get |
| 27 |
> completely different behavior. You remove it, you get completely |
| 28 |
> different behavior... |
| 29 |
|
| 30 |
Can you answer the same question removing ':=' ? |
| 31 |
I might have missed something but, as I see it, it is the same meaning |
| 32 |
with and without :=, and this just provides an algorithm on how to |
| 33 |
trigger the rebuilds. |
| 34 |
|
| 35 |
[...] |
| 36 |
> It is easy to write others how to do stuff without looking at the |
| 37 |
> code, isn't it? |
| 38 |
|
| 39 |
It is, indeed. But two things: |
| 40 |
|
| 41 |
1. If portage uses crafted depstrings in its depgraph when rebuilding a |
| 42 |
package and nobody is able to give me a good reason _why_ this is |
| 43 |
needed, I really do not want to look at the code :) |
| 44 |
|
| 45 |
2. From my experience, such input is very useful: Yes, it often annoys |
| 46 |
me and sometimes even pisses me off that some external guy comes and |
| 47 |
tells me I have to trash all that code I wrote, that costed me a lot, |
| 48 |
and even I have problems understanding it. But, in the end, more often |
| 49 |
than not, I realize that I was too much into the code and not enough |
| 50 |
into understanding and simplifying the global picture and that |
| 51 |
this external input allows me to make the code simpler, less buggy and |
| 52 |
much more maintainable. |
| 53 |
|
| 54 |
Alexis. |
Archives