On Wed, 3 Feb 2016, Lukas Tribus wrote:
But then again, when you do need that particular SMU, that isn't covered
by any SP yet, you can't apply it and you have to wait for the next SP
containing this fix - which kind of defeats the purpose.
I still expect Cisco to do some kind of "hotfix", which is what SMUs are
good at. Fixing some specific issue until next SR comes along.
My biggest objection was that historically one had to apply 40-50 SMUs at
a single time, some obsoleted others, some depended on others. It was just
hell to figure out how to get where one wanted to be. Often you found out
if you missed something after 30-60 minutes and you got a rejection
message that something went wrong. There was no mechanism for
automatically including SMUs that another SMU depended on.
So software application path should be (and this is what I hope they're
doing):
Version x.y.z
SR every 1-4 months, which rolls up all fixes and removes all previous
SMUs and SRs during install. SR has no dependencies apart from what
version it applies to.
SMUs for the last SR for hotfixes that are so new that the fix hasn't made
it into an SR yet.
I've been told XR 6.x will have a new package handler, I am curious to see
if that actually fixes a lot of the problems. I kept stating to people
involved with XR that the Debian apt tool was better in 2000 than the
package handling in XR in 2014.
--
Mikael Abrahamsson email: swm...@swm.pp.se
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
