On Wed, May 29, 2013 at 06:44:55AM -0400, Michael K. Johnson wrote: > Erase handling is not the best feature of system model, and it comes > down to the fact that "erase" is not well-specified. Does it mean > "erase-if-it-exists" or "erase-and-it-must-exist"?
what could be a reason for "erase-and-it-must-exist"? it would only make sense if the erase operation could leave something behind. but how can you know what that is without tracking the version of the groups at the time the erase was added. this is where the story model breaks down in my view. it does not account for changes of the groups over time. > And intermediate "erase" operations could potentially modify the > results of the system model; erase is order-dependent. can you give an example where this would make a difference? the only place i can think of is lines that change the groups to be searched. > I agree that this behavior is hard to understand. However, exactly > what is right to do is harder to know. that kind of suggests that there are actually different things conary could do in case of a erase of a non-existing package. i am ignoring errors on install or update, because i think there it is obvious that if a package can not be found it must be an error. for erase however, the case is different. it can be an error (because i got the wrong group) or it can be an obsolete line. there are two ways to resolve errors: remove the line or add a group. erasing the line has the same effect as ignoring the error. so the outcome of that is predictable, whereas adding a group would invalidate everything anyways so that is not predictable. there is no way conary could even attempt to guess which group should be added. (what it could do is check if the package is in a group added later, but that would really only lead to a suggestion to the user that the model could be changed by reordering lines, but not help conary solve the problem by itself.) in other words, i don't see anything hard in knowing what to do. it comes down to only two choices: that is to ignore the line that causes a error, or to abort. the current choice is to abort. > A system model is a kind of story. "Pretend that I had installed > this, updated that, erased that other thing, etc: find the state > in which that would leave the system and put it in that state." > The "updateall" operation updates all the version numbers, and > then re-runs the model. If lines in the system model do not make > sense in the new context, it's hard to know how to "rewrite the > story" to honor the original intent. The "erase" is the most common > case of this, but also an "install" of a version that later comes > to contradict a version added to a group can do the same, as when > a package is installed from a private repository on its way to being > added to the system group. true, but only a problem if i add a group from the private repo. in most cases the package would be added with a full path, and thus not be a problem. i am not concerned about special cases. a simple erase however i think is more common. > The good news is that this no longer depends on SAS to implement. > Nine years after we started developing Conary, we finally are in > a position to accept external contributions without copyright > assignment. After the necessary contributor agreement, which is > modeled on the Linux kernel Developer Certificate of Origin, is > added to the Conary source code, we will have the option to > incorporate external contributions that follow that process. that's great news indeed! the most annoying problem actually was that the errors are coming one by one. i mean if certain pachages no longer exist, then they will cause a problem regardless of the order, so there is no reason not to continue after an error and see if there are more errors. and then list all errors in one go. > I could imagine an option to "conary updateall" that would tell > it to remove (or potentially comment out) lines that cause > errors. I don't have a sense for how much work that would be. > That would clearly not be the default out of the box. It is > possible that the default setting for that behavior could be > set by a configuration option. i'd opt for neither remove nor comment out, but ignore such lines, if we want to offer a "make sure it's gone, and stays that way" option. the main problem for me is packages being removed from groups. and they could be added later, so the line makes sense again. i'd make a difference in dealing with erase and install errors. ignoring erase errors makes sense as an optional default or a simple commandline option. ignoring install errors doesn't make sense as a default, and should need a --force option. > Given such an option, there could be another similar one that > would clear out all no-op lines. It would slow processing a bit, > but that might be OK. But because "install" really means "make > sure this is installed, and it's OK if it was already installed" > in the system model language, that would have to be an option > or configuration setting. i don't think that is really that helpful. ignoring would solve most problems, and not make changes that are hard to recover from. if i ignore by mistake, i can easely unignore, but if conary removes lines without me realizing it, that it's a different issue. what would be more interesting is if install and erase commands can attempt to undo existing erase or install lines. the most common case i'd think is if i install a package, and later erase that same package. greetings, martin. -- eKita - the online platform for your entire academic life hackerspace beijing - http://societyserver.org/hackerspace-beijing/ -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net foresight developer realss.com foresightlinux.org unix sysadmin trainer developer societyserver.org Martin Bähr working in china http://societyserver.org/mbaehr/ _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
