Wiki source for Blog20101001MageiaMigrationPathForUsers

Show raw source

There are several scenarios possible for users to migrate to Mageia, depending on choices of version & structure of installation

====Scenarios for a migration path to Mageia for users====

~- users may be using an updated mdv 2010.1, 2010.0 would require more work and longer upgrade anyway (too many packages changed)
~- identifiy an easy method for several cases (to be identified)
~- virtual box install (at first, from boot.iso is the easier imho, it requires mirrors though for rpm tree, afterwards: liveCD iso or other?)
~- available ?

~- urpmi is used
~- boot.iso is working
~- draklive is working to make LiveCD
~- mirrors are available with rpm trees
~- short name is mga instead of mdv
~- user can use the network (perhaps add a disconnected update scenario? providing documentation to establish a local mirror of >30 GB rpms available)

~- reduce number of packages to update
~~- in rpm database, rename mdv2010.1 (as in evolution-2.30.3-1.1mdv2010.1) to mga, I do not know if it's possible?
~~- then launch ##""urpmi --auto-update""## # to take only into account updated packages
~~- hypothesis: version numbers are the same as with 2010.1 (not sure imho)
~~- maybe reinstalling is just more simple
~- structure of installation
~~- well, rather than /home on a dedicated partition, I prefer to have /data and make symbolic links for Documents / Videos & other directories
~- provide an updated 2010.1 ISO with appropriate trees
~~- costly in time, may require suficient testing as it's not only a "change artwork & take into account latest rpm in updates"
~~- may not include all rpm? (selection?) on mirrors
~~- ensure that a version can be installed
~- list of packages to update (to provide a list of downloads for example), if user does not have Internet access
~~- could be useful if many computers to update: make a subset of the mirror (no need for debug, specific architecture chosen)

identify limitations of the media, be it a live CD or even DVD
~- CD is 700 MB at most, good for live CD and testing, but for upgrading the repository is 30 GB with over 10000 SRPMS packages
~- DVD is 4 GB at most, good for upgrading "usual" installation (1000 to 2000 packages) but may miss many packages among 30 GB available :/
~- local mirror is suggested for update to avoid unexpected changes (most common error when upgrading) or download errors (less happening when locally), taking into account limited connectivity countries has been addressed on the ML, with an appropriate answer : contact your LUG :-)
===related subjects to make a decision===
IMHO, decision will come from involving as many people as possible on the project, so it has to be a working implementation for many people from the start (not just developers)
~- test the whole process (rpm tree + iso + mirroring) as soon as possible taking into account volumes for stable / development version
~- recompile as much as possible, then recruit maintainers for what exists (and additions for what's missing), identify teams that can make it work (maintainer + testers/users + documentation/i18n team + communication/marketing teams)
~- provide a working ISO rebranded ASAP for users to test both light-rolling-release or any other model (backports) and development version for cauldron

===examples of implementation===
==install from scratch==
~- in virtualbox
~- in a chroot (from debian for example)
~- on real hardware, make it known, see (h4l and smolts are good tools to evaluate hardware that just works)

==install by updating==
~- a live CD will miss too many packages :/ (others are available from mirror ?)

===Testing upgrade path===
~- tests can be done to upgrade existing installation of a 2010.1 or 2010.2 (in a vm for repeating purpose)
~- make sure that we are testing the most common path and not the least common one
~~- ie dispatch the task "someone test basic kde update" "someone test with plf source and most common package" etc
~~- if we use the same vm with the same command, we will have the same report ...
~~- should be as random as possible, i.e if you have a 2010.1 vm you've been using for sometime, clone it and try upgrading
~- report upgrade bugs and link upgrade issue to
~~- a tracker bug (i.e. open a new report and make it block 56)

# urpmi.removedia -a
# urpmi.addmedia --distrib local_mirror_to_prevent_hdlist_brake
# urpmi --debug --bug /root/log --replacefiles --auto-update --auto

~- adding vbox4 on 2010.2 ""urpmi virtualbox --search-media Backports"" tests according to LSB specification

CategoryBlogMageia CategoryMageiaInfo
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki