On 12/13/06, Jeremy Katz <katzj@xxxxxxxxxx> wrote:
On Wed, 2006-12-13 at 09:44 -0500, James Olin Oden wrote: > I might be able to live with this, but again I ask is this desirable > behavior? I can see after thinking through this a bit how in the case > where you were installling over an existing system and partitions were > not being cleared that there would have to be a bit more flexibility > as to the ordering of partitions, but I would have assumed that when > the partitions were cleared, you would end up with same order as was > specified in the kickstart file (implicitly via the order of the part > declerations in the kickstart file)? Is this not a reasonable > assumption? The ordering is deterministic, but it doesn't necessarily match the order that they're specified in. Due to wanting to be able to support partitions with --grow, the general way things work is that we allocate the biggest partitions first and then go down in size from there.[1] Jeremy [1] There's an exception that makes sure we allocate boot partitions first taking into account that different arches have different constraints.
OK that makes sense...in my case I can live with that, but wouldn't it also make sense to have the ability to allow the user to specify the order of the partitions (similar to --onpart, but the partition does not have to exist)? Which ananconda file would I need to change to develop a patch to provide for this (I already figure I would have to start in kickstart.py but I still have not located the sort algorithm (though I think I might have looked at it and did know what I was looking at))? Thanks...james
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
