Having been using dwm since it was pretty much added to the tree, and a little longer then that, this kind of thing bothers me a bit. I'd like to ask that the errors that are produced during an update to a new version be worked around (I'm sure this could be done in the ebuild. I'm sure it had been done before). Currently updating with a dwm update in the mix as well is proving very annoying, for this reason: >>> Unpacking dwm-3.5.tar.gz to /var/tmp/portage/x11-wm/dwm-3.5/work * Checking existence of //etc/portage/savedconfig/x11-wm/dwm-3.5 ... * Checking existence of //etc/portage/savedconfig/x11-wm/dwm-3.5 ... * Checking existence of //etc/portage/savedconfig/x11-wm/dwm ... * No saved config to restore - please remove USE=saveconfig or !!! ERROR: x11-wm/dwm-3.5 failed. Call stack: ebuild.sh, line 1614: Called dyn_unpack ebuild.sh, line 751: Called qa_call 'src_unpack' environment, line 1844: Called src_unpack dwm-3.5.ebuild, line 33: Called restore_config 'config.h' savedconfig.eclass, line 108: Called die !!! provide a configuration file in //etc/portage/savedconfig/x11-wm/dwm !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/x11-wm/dwm-3.5/temp/build.log'. I know this can be worked around, and seems to me to be more of a broken ebuild then something the user should have to fix by hand every time there is an update as opposed to a simple if-check in the ebuild to see if it does exist, and if not, continue on as if the file didn't exist, and doing a basic fix.
Eh, don't use USE=savedconfig globally; problem fixed. That's what /etc/portage/package.use is for.
my rational, which you may disagree with, is if you have specified the USE=savedconfig you have a config that you wish to restore into program. If the restore file doesn't exist then it is up to you to fix it because restoring from a config is what you specified. If it ignored a missing config then the eclass didn't do as you instructed.
(In reply to comment #2) > my rational, which you may disagree with, is if you have specified the > USE=savedconfig you have a config that you wish to restore into program. Which generally is the case. Thats why you use said USEflag, and since the format for the config file hasn't, and probably won't, change, then you could instead of looking for a full version number in the name, you could just change it to look for a major version number to differentiate between the old, broken format and the new format. > If the restore file doesn't exist then it is up to you to fix it because > restoring from a config is what you specified. If it ignored a missing config > then the eclass didn't do as you instructed. It still is broken, considering the fact this can easily kill a long update which someone may do while they are gone. This comes down to writting something that can handle a problem and fix it, or just crapping out when something that could easily be circumvented isn't.
(In reply to comment #3) > > If the restore file doesn't exist then it is up to you to fix it because > > restoring from a config is what you specified. If it ignored a missing config > > then the eclass didn't do as you instructed. > > It still is broken, considering the fact this can easily kill a long update > which someone may do while they are gone. Unrelated issue. Portage dying on first failed emerge is a different bug, move this to Bug 12768. > his comes down to writting something that can handle a problem and fix it, or > just crapping out when something that could easily be circumvented isn't. We shouldn't pretend that something succeeded when it failed because you didn't provide a suitable config, can lead to much more serious issues (think stuff like busybox etc.)
I'm happy with the error message. I'm sorry you're not however I'm going to stick to my belief if you USE=savedconfig you mean it and need to handle the config appropriately.
