On Sunday 06 February 2011 12:53:20 Cedric Sodhi wrote: > On Sun, Feb 06, 2011 at 10:56:53AM +0000, Neil Bothwick wrote: > > On Sun, 6 Feb 2011 10:31:49 +0100, Cedric Sodhi wrote: > > > 1. With a sudden change portage would simply resync to a new > > > directory, > > > > > > the old tree would rot in /usr > > > > And people would hit problems because /var bas filled up! I'm not saying > > the current default is right, it's not, but you are over-simplifying the > > work involved in making a change. > > I disagree. You are overcomplifying it instead. The proposed patch would > involve exactly: > > 1.) Change the default (the value that is used if no explicit value is > given) > > 2.) etc-update make.conf to explicitly specify the old location as the > desired value. > > Period.
If done simultaneously, it should work, yes.... > Patches have always required reviewing by the user through etc-update. Not patches, but changes to the configuration.... Usually, however, people choose to ignore the update as they don't want to go back to the "default" settings. > Your attempts to argue that patching portage with that simple change > would introduce problems of unpreceeded magnitude are pharisaic. It's > the same though significantly simpler as other updates to whatever > package you like. Wrong. When doing a "emerge -vauDN world" and a new portage is included, it will restart the emerge after portage is updated. At this point, make.conf will NOT have had the update as specified in your step 2 and will then proceed with the "new" default. This new default is empty and as such, the emerge-update will fail. How many people will then post on this list and file bug-reports based on a, in their view, broken portage? > Your argument that the developers should not be bothered with minor > issues such as this one because they have bigger issues is the > trillionth logical fallacy in this thread. I'm honestly tired of it and > I will not counter argue this because the wrongness of your reasoning > should be trivial to spot with at least a minimum of thought. Your choice not to accept this argument doesn't help either. There are a limited amount of developers and these have a limited amount of time. I don't know how many are actually employed by Gentoo, but I do believe that the vast majority is doing the work in their free time. > Hint: We (users & developers) have to first reach the decision that it > *should* be changed. We haven't even reach that point and are crawling > through a mud of ignorance instead. The responses in this thread are roughly of the following types: 1) "I don't care" 2) "Yes, it's wrong, but I don't bother changing it" 3) "Yes, it's wrong and I fixed it myself by changing the default" Unless I missed it, I don't think anyone actually said they want to keep the situation as it is because they are against changing it. > > Actually, the way to make the change is not to change the default, yet, > > but to change the default make.conf for new installs, and the > > accompanying documentation. That way existing systems are unaffected, > > which is how it should be with a change of default. I agree with this. To make a change like this, it would need to be done over a longer period with the following stages: 1) Change the documentation to add changing the default in "make.conf" 2) Change the "make.conf.example" to list the new default 3) Change the "make.conf" with the portage-package to the new default 4) Change portage to default to the new default Steps 1-3 can be done nearly simultaneously. (But will require time) Step 4 will have to wait till the vast majority has been informed. The most work will not be with the "code" (2-4), but will be with the documentation. Any howto/document/guide/.... on the internet currently mentions "/usr/portage/..." for the tree. All these would also need to be updated to at least mention the new default alongside the current one. To give an indication on the amount of references to "/usr/portage", enter that into your favourite search engine. Google gives over 300,000 hits just now. That, to me, does not seem like a "simple" task and it won't be a "minor" issue to fix. -- Joost
