to quickly summerize previous emails: - an algorithm: if x then y; else if xx then yy ; else...... - relied on algorithm but did not ensure consistency - a misunderstanding of the use of 'zypper up' on TW - a misunderstanding of what ---no-allow-vendor-change actually does - conflation with the handling of Leap - the inapropriate use of locks - various rants none of them as simple or clear as using "zypper dup ---no-allow-vendor- change" for the typical update
I would apologise but given your post made it clear you felt the learning curve for zypper was too steep, I thought you would appreciate the context behind some of the status quo understood
Beyond that, your opinion is noted, and I agree with you
But whether I agree with you or not is immaterial - someone has to contribute changes to make what me and you think is right into reality if we decide on a way forward i will happily change the code.
The purpose of the post was to: 1 - articulate a perceived problem, solicit points of view, check understanding. 2 - get proposals on a solution, decide on implementation implementation has not been decided, there are several options: [remembering that TW users may update several times a week] a - simply be more aware and consistent in recommending the use of zypper dup ---no-allow-vendor-change" in documentation/forums etc b - (hack) add an alias to .bashrc --> better tell the user to add it. c - adding a new command to zypper e.g. ldup (l for locked) -> SUSE might object? d - [probably the cleanest/easiest] adding a new flag zypper dup --lock (or simply dup -L or -LV) (as in Lock Vendor) *my vote is for zypper dup -LV* (if factory mailing list is not the place to collaborativly work on solving a problem, and creating consensus for the implimention of changes - you should let me know -> how is TW design actually done?) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org