On 8/15/07, Vaeth <[EMAIL PROTECTED]> wrote: > On Tue, 14 Aug 2007, Alec Warner wrote: > > On 8/13/07, Nathan Smith <[EMAIL PROTECTED]> wrote: > > > > > > I suppose this comes down to weighing the utility of such a feature > > > against the amount of effort which would go into adding it to Portage. > > > > Its trivial to implement, but I think its a long standing decision of > > the portage team to not do it. > > Please allow me to give some arguments why maybe this decision should be > thought over once more: > > > We typically don't write things for emerge that touch your > > /etc/portage files (aside from updates/) > > Which is good. > There is no need to change such a file for the required feature > (only oppositely: Without the feature, the user is forced to change > this files) > > > We also don' t like one-offs. We used to recommend people do stuff like > > "ACCEPT_KEYWORDS=~x86 emerge foo" > > or > > "USE='foo bar baz' emerge foo" > > > > which both suck because the next time you use emerge > > your settings are lost. > > With the second claim I completely agree: > It is good to not recommend such things in general (in particular, > not to an unexperienced user). > However, I cannot see why one-offs should be bad in general: > There are always cases where people *intentionally* want one-offs. > For USE or ACCEPT_KEYWORDS, this might simply be for a (temporary) > testing purpose. However, concerning the selection of packages which are > updated there are more serious reasons why one might want a one-off. > Some examples: > 1. You want to upgrade a machine, but also a new version of > openoffice would be installed for which you currently do not > have the bandwidth to download or the time to install. > So you want to emerge -NDu world except for openoffice. > Of course, one might argue that you should then put the new version > of openoffice in /etc/portage/package.mask, but actually, you would > like to see openoffice in the next emerge command again - in fact, > when you call emerge next time you might even have forgotten that > you had masked openoffice the previous time for a temporary reason. > 2. You want to upgrade a machine which should do something in the > next 24 hours (e.g. record a movie) and you suspect that the > suggested upgrade of e.g. expat might break the application without > a revdep-rebuild. So you want to emerge -NDu world except for > expat. (And, of course, you will want to emerge expat next time). > 3. You have reached your band-limit for this month and so cannot afford > to download the new kernel sources until next week. So you want to > emerge -fDu world except for the new kernel (and perhaps later > emerge -Du world except for the new kernel). > 4. You want to upgrade on your laptop 100 binary packages. However, > since your laptop has only a small harddisk, these 100 *.tbz2's do > not fit all on your laptop - you should exclude 3 or 4 of the large > ones in the first step and then can install these large ones > in the second step. > > In all of the above cases you usually want that the corresponding > packages are contained in the next emerge -NDu world; you just want > to exclude the packages for one particular call of emerge.
Ahh but that is a lie. You want to exclude the package from the depgraph until whatever reason you had is gone. Typically it's 1 emerge run, sometimes it's 100's, I don't think you can necessarily limit the number of emerge runs in any of the use cases. In the case of bandwidth limitations, you want to not download the kernel until you have more bandwidth available. Are you going to remember to exclude the kernel sources every time you run an emerge that might pull in kernel-sources? God knows I wouldn't remember ;) So the point of this discussion is that specifying things that affect the resultant depgraph are bad unless they have useful functionality. ROOT and CONFIG_ROOT are two such options, but afaik those can also be set in make.conf (have to read the code to check). > But why force the user to hack to achieve a reasonable goal? > The files in /etc/portage/* should IMHO be well cared by the user > and not be misused for temporary hacks. > Moreover, if you modify e.g. package.mask just to get one of the tasks > in the above example done, it is easy to forget to undo > this modification after the emerge. Well I wouldn't say making a wrapper around emerge is a 'hack'. It's not like it requires editing the code. Your latter example about not removing the mask is mitigated by using a tool (mask, run emerge, unmask). If you want to talk about how emerge sucks as a tool to manage /etc/portage/* then I'll wholeheartedly agree with you. Feel free to write some. But emerge is not an /etc/portage/* manager. -Alec -- [EMAIL PROTECTED] mailing list
