On Wed, May 29, 2013 at 03:43:58PM +0200, Martin Baehr wrote: > 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.
Well, the point is to avoid nonsense. Imagine if it's "erase group-foo" and then group-foo goes away, and then later comes back with different semantics, and the erase line stuck around without doing anything in the meantime... > this is where the story model breaks down in my view. it does not > account for changes of the groups over time. I'm not sure how one would account for that in any automatic system. I mean, group changes over time are semantic changes that can't be handle a priori. > > 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? At least erasing a group... > 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. I don't like ignoring the line. Changing it (such as commenting it out) would give some temporal stability. > i am not concerned about special cases. a simple erase however i think > is more common. I have to be concerned about special cases. Hacking a common case while ignoring special cases tends to cause additional more intractable problems. > 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. Well, the problem in general is that errors can change whether the rest of the model makes sense... > > 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. Well, one complication is that the system model language is another way to get at the same basic code that is used for building groups in the new "GroupSetRecipe" case, to the point that one way to build groups is to use the system model language. At least in that case, an "erase" of a package that does not exist is a clear error... > i don't think that is really that helpful. ignoring would solve most > problems, and not make changes that are hard to recover from. Well, perhaps a configuration for ignoring errors. But we do need to keep in mind the use of system model where you can define as system in the system model language, and then use the system-model file to create that group, and in that context all such errors should be fatal, so we can't have them be explicitly and only incompatible. > what would be more interesting is if install and erase commands can > attempt to undo existing erase or install lines. erase will actually undo install if it's an exact match and the most recent line and it has the same impact. There are tests that demonstrate that happening, as I recall. _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
