* Susanne Oberhauser
Klaus Kaempf
writes: * Susanne Oberhauser
[Sep 26. 2008 16:09]: Hi,
thx to some kind pointer off-list I found and checked http://en.opensuse.org/Product_Management/Code11/Upgrade
This all looks great as long as you don't depend on an add-on with KMPs (aka driver kit) to get your machine booting.
Well, if you need a driver for _booting_, driverupdate (aka 'dud') is your friend: http://en.opensuse.org/Linuxrc#p_driverupdate
For initial install, I agree.
For an update, I don't understand: the driver kit update is available online, in parallel to the the base product:
SLE GA -> SLE SP1 driver kit for SLE GA -> driver kit for SLE SP1
Right, thats the ideal case when a (3rd party) driver is available with SP1.
If the kernel and the drivers are updated in one run, then there is no need for a DUD.
If you do the update in the running system, there is no need for a DUD.
So why are you mentioning a DUD in a discussion of a system update?
If you update by booting from a DVD, you might need a DUD.
The 'to be removed' packages are explicitly listed.
Which is good.
However what I'm talkign about is the following current siutation:
SLE GA + some driver kit for SLE GA
is updated to
SLE SP1 without driver kit
This update will not work. Except if you explicitly remove the drivers with broken dependencies.
and then 'somehow' you need to get that to
SLE SP1 + driver kit for SP1
What I'm proposing is to update the registered repos for base product and add-ons in _one_ step, and then to update the packages for all updated repos in one second step, and to only reboot after all packages have been updated:
SLE GA + some driver kit for SLE GA
is updated to
SLE SP1 + driver kit for SP1
in 'one' step.
Thats what the upgrade process is trying to do. Ideally, NCC knows your system and reports all repositories needed for a successful SP migration. However, this will only work with driver repositories we know (resp. have control over). If a customer has additional driver repositories added (or some repositories don't have SP1 drivers available), this 'one step' scenario will break.
Have we ever considered refining the 'package locking' into 'remember what the user wanted'?
i.e. wich resolvables did the user ever explicitely select and which ones were autogenerated?
Yes.
Now as having the system and it's components accessible to me seems like something desirable in gneral, I'd lift driver kits that were registered by Jockey into the class of 'explicitely selected resolvables', too.
Drivers might be automatically installed due to hardware dependencies (http://en.opensuse.org/Software_Management/Dependencies/Hardware).
Then a Release n+1 migration will only succeede once all the driver kits can also me migrated.
Right.
Or the user explicitely deselects the driver kits, and that can then come with a warning 'if you remove this instsource, you may loose hardware functionality'.
that would be more helpfull than the current package level locking, and it would also be more helfull than the current long list of packages that will be removed now.
This requires knowledge about which package came from which repository. The just introduced 'package logging' provides this functionality.
- There needs to be a way to migrate several repos in one step simultanously, so the kernel and the KMPs get updated in one single step, before reboot.
The update stack in 11.1 / SLE11 supports 'services', a collection of repositories. See http://duncan.mac-vicar.com/blog/archives/351
However, this requires knowledge of old and new repositories which is hard to collect.
If the SLE GA repo gets an optional patch which updates to the next SP, then the driver kit's repo can get a corresponding patch that migrates to the driver kit's successor.
For driver repositories controlled by Novell, yes, this can work. For other 3rd party repositories, its up to the customer to track down the correct drivers. (And push the driver vendor to get the driver upstream ;-)). Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org