On 05/29/2013 10:53 PM, Mark Trompell wrote:
Am Wed, 29 May 2013 16:20:25 -0400
schrieb "Michael K. Johnson" <[email protected]>:
I don't like ignoring the line.
Changing it (such as commenting it out) would give some temporal
stability.
Wouldn't it make sense if conary would go into an interactive mode
informing the user that it found an entry that doesn't make sense
(triggers an error) and asks what to do (ignore, abort, remove entry)
+ Having a switch to not do that but exit on error?
I can think of a couple of perspectives here:
1. [my system] A capable (power) user who is wise to Conary and who
manages his own daily-use systems
2. [server-model] A capable (power) user who is wise to Conary and who
manages roll-out on a range of systems which serve user requests
3. [grandma] A 'grandma' user who relies on someone else to manage their
system-model
To me it seems that while use case 1. [my system] might benefit from
being dropped to $EDITOR /etc/conary/system-model, both use case 2.
[server-model] and 3. [grandma] would not benefit from automatically
dropping into an interactive mode, suggesting that it should not be the
default option.
To me, commenting out the offending line is functionally similar to
ignoring it/removing it with the exception that the comment can
explicitly state why it was commented out by conary. In the context of
ensuring that the system-model story makes sense from the newest
repository group perspective, commenting out seems to me to be the
wisest course of action. System-model is about specification, story and
context after all.
In case 3. [grandma], it might be ok to comment out offending lines
while issuing a warning at the end of the run (which should also be
logged). If we assume that grandma prefers having a working system
until her support person can find time to edit the system-model story
appropriately, commenting out the offending lines would probably even be
preferable over the option of dying a thousand flaming deaths and
spewing error messages to the console (and the log). To me, the only
question is if it is better to stick to the original story -- i.e. have
conary give up noisily and roll back to a known working state (issuing
and logging a warning) instead of having it try to best-guess its way to
a sensible system-model story given the new state of the upstream
repository group?
In case 2. [server-model], it probably won't be a good idea to ignore
the now inconsistent system-model (what if it is wrong due to some silly
error?) -- rather, giving up noisily and not modifying the system might
be preferable?
In summary, I would suggest that the default behavior should be to give
up noisly and not change the system, if the current system-model is
inconsistent when matched against the new upstream repository group. In
addition, I would suggest adding two new flags:
--interactive:
In the event that the current system-model is inconsistent when matched
against the new upstream repository group, issue a warning describing
the issue and the suggested change and offer me the option to
a: Accept the change and re-run the conary command with the new
(automatically edited) system-model
e: Accept the change and exit, allowing me to inspect or edit the
modified /etc/conary/system-model manually
q: Abort without modifying the system
--best-effort:
The same logic as option a: above. Specifying both --interactive and
--best-effort is an error, which should result in conary exiting,
telling the user that '--best-effort' and '--interactive' are mutually
exclusive options.
Would that work?
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
