Revision [274]
This is an old revision of Blog20101001MageiaMigrationPathForUsers made by BenoitAudouard on 2010-11-05 22:43:26.
Scenarios for a migration path to Mageia for users
requirements
- 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?)
- http://mageia.org/mirrors.xml available ?
hypothesis
- 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?)
ideas
- 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)
http://www.eclipse.org/projects/dev_process/development_process_2010.php
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 http://faq.tuxfamily.org/CommunicationLibreHardware/En (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 ?)
CategoryBlogMageia CategoryMageiaInfo