Re: [gentoo-user] A portage nuisance

[Anthony Youngman]

On 28/10/17 21:50, Alan McKinnon wrote:
> On 28/10/2017 22:39, Anthony Youngman wrote:
>> On 28/10/17 20:54, Alan McKinnon wrote:
>>> Portage cannot do that, it is backed by silicon and has no concept of
>>> meaning. So it has only one real choice - it can do it all or it does
>>> not try.
>>>
>>> I'm not surprised Zac never tried implementing partial graph resolution
>>> for the very simple reason that if you try do it, you have no idea what
>>> is going to be built. That is the opposite of what portage must deliver.
>>
>> Why is it the opposite of what portage *must* deliver? All I'm asking is
>> that portage build *what it can*. In other words, I know EXACTLY what it
>> is going to deliver - its best effort!
>
> Dude, calm down. Showing me that you are upset isn't going to change
> jack shit.
>
Sorry - I'm not upset. I just think you are missing what I'm asking for.
>>
>> And why does portage *have* to choose between all or nothing? All I'm
>> asking is that if it can't resolve everything, I want it to resolve
>> everything it can. Silicon is perfectly capable of making that decision.
>
> because "everything it can" is not necessarily the same thing as
> "everything it should" or "everything it was asked to do"
>
> Portage has no idea at all why the depgraph failed to resolve fully at
> the start. It knows about blockers that are in it's own ebuilds and can
> deal with those; the way ebuilds are spec'ed a package manager can
> cleave off an entire branch of the tree and build the remainder fully
> confident that each part of what it then does build is identical to the
> same parts if the blockers never hit the rest. It's deterministic and so
> portage can continue.
>
And if we are understanding each other correctly, THIS is the point at 
which I would expect portage to give up and terminate. Except you seem 
to be saying it doesn't terminate here ...

> For everything else, the input is not completely known therefore the
> output cannot be completely known either and portage does the correct
> thing and not try guess. This is a good thing.
>
You think it terminates here ...
>>
>> If I say "emerge -u world" I have no idea what it's going to build, if I
>> say "emerge -u best-efforts", I have no idea what it's going to build,
>> where's the difference?
>>
>> What I do know, is if I repeat "emerge -u best-efforts" several times, I
>> will end up (in all likelihood) with the same result as "emerge -u world".
>
> No, you will not. In this case, what portage will give is not the sum of
> it's individual parts as there is a real risk that some attributes of
> the various parts are WRONG. Therefore the output can be WRONG. It
> really is that simple.

When I run portage, it displays a list of what it is going to emerge. As 
I understand it, as each package is displayed of what it is going to 
emerge, that means it has successfully resolved the dependency graph. It 
also displays packages that are blocked. And then sometimes it just goes 
into a tizzy and says "too many blocks - giving up".

All I'm asking is that as it progresses, it makes a list of those 
packages it can resolve the dependencies for. If it then gives up with 
the current list it's processing, eg "world", it then goes back to the 
list it thinks it can process, and has another go with them.

Because that's exactly what I do, take the first few packages off the 
list that look fine, and emerge them. I then re-run the original emerge, 
rinse and repeat, but it takes absolutely ages, and worse I have to 
babysit the emerge because I'm *expecting* it to hit a problem.
>
> You even said it yourself when you used the phrase "in all likelihood".
> What about when it isn't? This is a package manager and package managers
> have one singular objective that the code must always deliver: the
> output must be entirely deterministic. Anything other than that and you
> do not have a package manager anymore, now you have software that puts
> stuff on a disk.
>
> Portage is doing the right thing when it detects invalid input that it
> cannot reliably  - it stops.

Why can't it just discard the invalid input, and try again with input 
that appears valid?

Note I didn't say *continue* - I said "try again". From the beginning.

I'm sorry, but the current behaviour is reminiscent of the way 
programmers (used to) code huge green-screen input forms - when you get 
to the bottom and hit "submit" - one error and it throws the whole lot 
away and makes you start again from scratch!
>
> But feel free to disagree. If you can do this, the proof is in code and
> patches. Got any?
>
What language? Python? Sorry, at the moment I don't speak Python - maybe 
I should.

And I hate to say it, but demanding code and patches is NOT good form. 
Yes, far too many people do it, but not everybody is a programmer (I am, 
but it's C and DataBasic). And do you REALLY want jack-of-all-trades 
giving you dodgy code? I contribute elsewhere. Fixing emerge is not 
really my thing, I'm just chucking out an idea I would find very useful 
(and I expect other people will too). I'm one of those odd people who 
actually *enjoy* maintenance work, rather than new stuff, and I'm hoping 
someone like me in the gentoo project will pick up this idea and run 
with it. I'm busy doing maintenance work elsewhere with what time I have ...

To give you a very clear example of what I'm thinking ...

emerge -u world
A will be emerged with options ...
B will be emerged with options ...
C will be emerged with options ...
D is blocked by E
F will be emerged with options ...
G is blocked by H
Giving up, too many circular dependencies
emerge A B C F
...
...
...

That is what I do manually, it would be nice if emerge could do it for me.

Cheers,
Wol