Boxed version of Fedora

[Gian Paolo Mureddu]

Ian Weller escribió:
> On Sun, 23 Mar 2008, Rahul Sundaram wrote:
>> If you have a Fedora store, selling a box as one of several items 
>> available seems very logical and what users would expect.
>
> +1.  Also, it's not like the user is necessarily going to update to each
> version, and they're not necessarily gonna buy it each time.
>

For this approach it would be *very* convenient to have a clean upgrade 
path from release to release through yum, or other program that uses yum 
as its backend to ensure stuff like user settings are migrated to the 
new version as painlessly as possible. System settings are harder to 
deal with, but at least user data should be "simple" enough for an 
automated process. The hardest part is without a doubt the partitionning 
of the disk space, especially since Fedora uses LVM as default. However 
this can be circumvented by creating two volumes and assigning at least 
a minimum % of disk space to be set as /home, so user data can be 
migrated from release to release. The "system" part of this migration 
would involve four files: passwd, group, gshadow and shadow, however, 
since in Fedora default user profiles use uid and gid numbers of 500 on 
ward, isolating these instances with association to directories found 
under /home, would be relatively easy to perform from within Anaconda, 
and for user-created groups, this could also be possible by checking 
user members of these groups and their associated /home directory to be 
migrated. However this work, as fas as I know, has not been done to 
Anaconda (I should really start learning Python!), though it could be 
relatively easy to do through use of shell scripts. The partition 
template is what I wouldn't know how to do. Still if a user has an older 
layout, how to migrate the user data? This poses a big problem, as the 
disk partitionning and formatting will erase all contents of the disk, 
so this could only be done by having a minimum version of Fedora which 
can be upgraded (for example, upgrade support only available from F10 
onward, which upgrade is possible from F10 to F11, but not from F9 to 
F10). I know these ideas would have to be discussed in the -devel 
mailing list or IRC channel, but this underlying infrastructure would 
certainly make more feasible a retail model of having only odd or even 
release numbers available through retail. I know there is much more 
involved in system upgrade than user data and application and system 
configuration data, and that usually upgraded systems feel less 
responsive than installed-from-scratch systems, but it could be a start.