On Wed, 2006-12-13 at 13:11 -0500, James Olin Oden wrote: > 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] > > > > [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)? It's actually remarkably non-trivial to do so with the way that libparted works. It also makes things very complicated to present to the user due to differences in partition tables across arches. > 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))? All the magic for this is hidden away in autopart.py Jeremy
