>> > 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. >> update[1] does this via the SKIP env var (if it's just for that one session or run.) Mr Warner is right IMO; the package manager is not the automated part. Its job is to keep your system consistent and provide an environment for building all kinds of software (broad strokes). If a user can do it, it can be scripted, with questions at decision points, or the safe bet for automatic usage.
>> 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. If you want to do it more permanently, you can add the package to noCompile (eg for OpenOffice, means it only updates it when you explicitly tell it to) or noRebuild (defaults to kernel sources and linux-headers internally) or noDowngrade (gcc and linux-headers will never downgrade unless you force it to with -X.) >> Your latter example about not removing the mask is mitigated by using a tool (mask, run emerge, unmask). > We tried to do this for the expat stuff with WARN (which is a make.conf style variable.) Unfortunately when we added =dev-libs/expat-2* to package.mask it didn't work, so we commented out that stuff until we could see what the problem is. (We needed to put the beta_2 out as there were a couple of bugs affecting users.) The idea of retrying the emerge is interesting though; it's how it handles blockers which you tell it to clean out. (This version also has support for blockers which are about to be fulfilled, to help us with the KDE upgrade.) > Unfortunately, such a tool always has side effects. > Just imagine the situation that you started an update (with something > temporarily excluded) and then realize that your net access will > soon go down [which is not unusual on a laptop] and therefore you want > to download everything with emerge -f... > Even with portage running, I /think/ you can emerge -f the rest; so long as you're not installing stuff at the same time, there isn't an issue. That'll download the files to the same place (distfiles), and the subsequent emerges won't need to fetch them. TBH though, FEATURES=parallel-fetch always gets files way before they're needed. (update has -f for fetch-first and -F for fetch-only, since it can't parallel-fetch.) > Anyway, meanwhile the situation has become much better by allowing > directories for /etc/portage/package.*: One can add the temporary hacks > into a special file like /etc/portage/package.mask/onlynow > and then remove this file without modifying the "more permanent" stuff. Yeah that's what we did with update (if there's a directory.) The real concern is if the user only has a file, and we modify it and then the system goes down. We built in a check for the backup file when it starts, and it does actually lock pretty reliably (you can also use update --stop to get it to stop /after/ the next package.) The temporary mask thing needs more testing, so WARN is disabled atm. The code is all still there though. (It also wraps glsa-check and the new revdep-rebuild nicely; we're working on a dialog for depclean.) > Unfortunately, this approach is not possible > for /etc/portage/profiles/package.provided which might be sometimes needed > if masking is not possible (e.g. if something else depends on the masked > version). Well as I understand it, the package doesn't need to go in provided if it's actually been installed by portage. package.provided is for packages you install yourself from source, and you want portage to know that it can be counted on during dependency resolution. (So it won't try and reinstall something over the top of your custom version.) [1] http://forums.gentoo.org/viewtopic-t-546828.html -- [EMAIL PROTECTED] mailing list
