| 1 |
On Fri, Aug 1, 2014 at 9:03 AM, hasufell <hasufell@g.o> wrote: |
| 2 |
> Rich Freeman: |
| 3 |
>>> |
| 4 |
>>> Tree policy, I'm afraid, has to adapt to Portage; not the other way |
| 5 |
>>> around. |
| 6 |
>> |
| 7 |
>> The reality is that both portage and the tree policy need to adapt to |
| 8 |
>> the needs of the community, otherwise there won't be anybody around |
| 9 |
>> maintaining either. |
| 10 |
> |
| 11 |
> Rich, we are almost at the point where portage is unmaintained. Can't |
| 12 |
> say I feel sorry about that. I'd rather hack on paludis than portage |
| 13 |
> (although it isn't exactly well documented and would probably take me 2+ |
| 14 |
> months just to understand some basics). |
| 15 |
|
| 16 |
So, if you want an example of why I think most people prefer portage |
| 17 |
to paludis, I'd bring up @preserved-rebuild. It is the biggest hack |
| 18 |
that anybody could have come up with, and I can easily list 47 ways of |
| 19 |
why the way paludis does things is more |
| 20 |
elegant/accurate/well-behaved/etc. |
| 21 |
|
| 22 |
The thing is, with @preserved-rebuild I don't have to run |
| 23 |
revdep-rebuild for the packages that either can't be or simply aren't |
| 24 |
migrated to slot operator deps. That is a huge win. Also, random |
| 25 |
things aren't broken during the time that I'm rebuilding, so I don't |
| 26 |
end up chrooting into my system from a rescue CD when I forget to run |
| 27 |
revdep-rebuild. I'll be happy when the day comes when we can get rid |
| 28 |
of it, but that day is not yet here. |
| 29 |
|
| 30 |
Generally speaking portage has favored usability over beauty of |
| 31 |
design. That has made it harder to maintain, but far more popular. |
| 32 |
|
| 33 |
And don't get me wrong - I ran paludis for years. I didn't migrate |
| 34 |
back to portage until it began to do more than just resolve |
| 35 |
dependencies. |
| 36 |
|
| 37 |
> |
| 38 |
> Anyway, I don't think the recent reactions help in any way to boost |
| 39 |
> portage development. People should really think about this and how this |
| 40 |
> is perceived by the remaining portage devs. If you guys want to actually |
| 41 |
> help portage, you should come up with code fixes that reduce the number |
| 42 |
> of rebuilds instead of voting on unimplemented solutions (which I think |
| 43 |
> is highly contradictory). |
| 44 |
> |
| 45 |
|
| 46 |
If we're just going to turn portage into paludis, why would we bother? |
| 47 |
I think that paludis largely exemplifies this kind of design already, |
| 48 |
or it least it did so back when I was running it. |
| 49 |
|
| 50 |
And what I'm really asking for here is for somebody to actually |
| 51 |
explain what is actually wrong with dynamic dependencies. I have seen |
| 52 |
47 almost-certainly-sincere claims that they're broken, but little in |
| 53 |
the way of examples, and the one that has been given (prerm) seems |
| 54 |
likely to break with static deps the way it is implemented today (we |
| 55 |
don't unmerge reverse-deps before upgrading the dep, which breaks |
| 56 |
linking that might be required to unmerge the package in the first |
| 57 |
place - though it probably only breaks 0.01% of the time and the cure |
| 58 |
is likely worse than the disease). |
| 59 |
|
| 60 |
The last thing I want to do here is frustrate somebody who is doing |
| 61 |
the right thing. I'd just like to understand their thinking, and I |
| 62 |
think many others would like to understand as well. |
| 63 |
|
| 64 |
Rich |
Archives