On Sat, 22 Mar 2008, Gian Paolo Mureddu wrote:
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.
How does Ubuntu do it? I remember upgrading my sister's computer with
one click, and it appeared to work perfectly -- until she decided to
unplug the computer during the upgrade. >.< I have no clue what the end
result would've been, but it was probably the best upgrade interface
ever.
--
Fedora-marketing-list mailing list
Fedora-marketing-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-marketing-list
