On Tuesday, July 26, 2011 01:51:18 AM 夜神 岩男 wrote: > This is roughly what Microsoft used to aim for (somewhere on the road > between XP and 8 they seem to have totally quit the idea, though).
As a slightly off-topic aside, there is a youtube video out there about doing just that; the video shows an upgrade chain that goes from Windows 1.0 (no, that's not a typo) up through Windows 7, all as upgrades, along with all the things that have to be changed along the way.... some of the text the guy enters in textboxes is NSFW, however. So you'll have to google for it yourselves; it made Slashdot a few weeks back, so it shouldn't be hard to find. I'm sure that some of these major upgrades *can* be done, but in a land where the package is the unit of OS granularity, and package maintenance practices vary from package to package as to 'upgradeableness,' it really becomes a task, and this is before even considering the upgrade-hostile attitudes of some software projects that upstream ships packaged in upstream EL. While package groups give an illusion of a unit larger than a package, it's just an illusion, really. The collective set of dependencies defines the full distribution, and nothing in the dependency chain requires rigorous, tested, upgrade path implementation. In the case of other commercial vendors doing this, well, those vendors typically have strict and tight control over all the developers working on it, and have enforcement mechanisms in place to ensure that migration paths are implemented. It's called an employment contract, and it's enforced through the ordinary commercial developer chain of command. While open source developers and packagers are technically capable of doing this, some seem to take great delight in making it difficult to be compatible (partly to prevent closed-source programs from continuing to work). And if just one development group becomes the proverbial fly in the ointment, then all the users of that package that need upgrades to 'just work' suffer. And sometimes the developers care, and sometimes they don't. But consider: upstream doesn't employ a 'critical mass' of developers in all of its shipped packages to reliably enforce upgrade provisions, even if it wanted to do so. Beyond that, there are packages supported by upstream that have serious difficulties with major version upgrades, simply because supporting data in place upgrades is not a priority for that development group. I can think of more than one project that seems 'upgrade hostile' but in reality it's just something that's not front burner; they'd rather develop newer features and fix bugs than 'waste' time on a rarely used procedure that is, in some cases, extremely complex and in other cases simply won't work anyway. That is, there are data sets associated with some upstream packages that are impossible to migrate in place to a newer version in a seamless, nondisruptive, fashion. In a nutshell, it becomes a tradeoff of open source freedom versus the upgrade needs of the users. If the needs of the users trump the freedom of the developers, then developer freedom (the freedom to 'scratch ones own itch'), the very essence of open source, goes out the window. To the OP, if your itch is to have seamless in-place upgrades, then scratch that itch (or pay someone what scratching that itch is really worth... but be prepared to come up with six or seven figures). That's going to be a mighty big itch, though..... especially with over 2,500 upstream packages from nearly as many heterogeneous development groups with many more agendas of their own. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
