Re: Boxed version of Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
Fedora-marketing-list mailing list
Fedora-marketing-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-marketing-list

[Index of Archives]     [Fedora Mentors]     [Kernel Developers]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Users]     [Yosemite Camping]

  Powered by Linux