Hi, following on from the emerge problems mentioned in bug #127033, I propose to replace "deep" with "shallow", making "deep" the default emerge option unless --shallow is specified. The enclosed patches relate to portage-2.1_rc3-r5
This has been discussed previously, the result was no.
Created attachment 88175 [details, diff] emergehelp.py.diff
Created attachment 88176 [details, diff] emerge.diff
My main argument against this is that changes to default settings often upset users and generate lots of noise for us portage devs. You can simply add EMERGE_DEFAULT_OPTS="--deep" to make.conf if you like.
Of course people who like to moan about change, will moan about it. The only reason they don't moan about the current default, is because they don't know the difference. I'm sure they moan to themselves quietly when their xorg upgrades fail :) Was there a technical reason why deep is not the default?
A. It's a behavior change B. emerge -u <pkg> would imply deep, which is probably not what most people want. I know it's not what i want ;) C. I would *maybe* support --deep being default for a set target...but even then I'm not liking it. Mostly because you have set targets implying different things than normal targets; not a good thing ;) >You can simply add >EMERGE_DEFAULT_OPTS="--deep" to make.conf if you like. WORKSFORME here.
I don't see a compelling reason for this change.
It's a behaviour *improvement*. I fail to see how non-obvious dependencies causing seemingly-random emerge failures is a good thing. The purpose of a package manager is to take away that annoyance. Who's the target audience for Gentoo? If it's people who already have years of experience with Linux From Scratch, then I can understand leaving the defaults in "expert-mode". But, if you're trying to encourage newbies, then change the defaults to protect the user from his own inexperience.
The last time I tried to change a default option, it disturbed lots of people. It's simply not work the noise. See bug 134466 for an example.
(In reply to comment #9) > The last time I tried to change a default option, it disturbed lots of people. > It's simply not work the noise. That sounds like a tired attitude. It raised debate by interested parties - isn't that a *good* thing? My comment re that bug is to show "[Y]", to make it obvious that "yes" is the default option when Enter is pressed. My problem, with *this* bug, is that the people who would most benefit from the patch are the newbies who don't even know this bug exists, or what it means :)
What exactly would it improve? So far I've only seen some vague assumptions. Btw, I just played a bit around with -p, -pD, -pu and -puD and generally -pD doesn't behave differently than just -p, only difference is when the target is world or system (which imply -u). -D is only useful in combination with -u, so should we also make -u the default? That would change the default behavior of "upgrade/install what's necessary" to "upgrade/install what's possible" for every single package install, I can see a lot off people getting quite upset about that.
(In reply to comment #10) > That sounds like a tired attitude. It raised debate by interested parties - Some things just aren't worth spending much time on debating. Changing default behavior has the potential to upset lots of people. Frankly, I have much better things to do than debate about what the "best" defaults are.
Created attachment 88192 [details] sys-apps.zip (In reply to comment #11) > -D is only useful in combination with -u. Yeah. Here's an example of what I think "deep" *without* "update" should fix. emerge lev3 (this installs lev2 and lev1) emerge --unmerge lev1 Now, I'm hoping to create a patch whereby a subsequent "emerge -D lev3" will re-install lev1, by traversing deeply down the dependencies, rather than ignore lev2's dependency on lev1.
(In reply to comment #13) > Created an attachment (id=88192) [edit] > sys-apps.zip tarball, for the future, not ZIP. Not everyone has zip installed. > > (In reply to comment #11) > > -D is only useful in combination with -u. > > Yeah. Here's an example of what I think "deep" *without* "update" should fix. > > emerge lev3 (this installs lev2 and lev1) > emerge --unmerge lev1 > > Now, I'm hoping to create a patch whereby a subsequent "emerge -D lev3" will > re-install lev1, by traversing deeply down the dependencies, rather than ignore > lev2's dependency on lev1. > Please file a seperate bug for your request
