On 12/13/06, Jeremy Katz <katzj@xxxxxxxxxx> wrote:
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.
Hmmm...sounds like that tool has created an insufficient model of reality.
It also makes things very complicated to present to
the user due to differences in partition tables across arches.
I'm only thinking of i386, which you can't. That said in any
environment I've worked disks are typically represented as a linear
array of bytes that can be "partitioned". Different wrinkles here and
there of course. I can say that having some way to let the user
order the disk partitions in some intuitieve way (other than using
your size algorithm) would be appealing to some. The two things that
will bother others I would think would be:
- It violates the principle of least suprises or its not intuitive
that the order should
differ than as specified.
- Essentially, you have limited what can be done to the partion
table via your
tools for what "appears" to be no good reason.
That said, I mostly fine with it since I see that ultimately no harm
is done. Its just confusing.
> 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
Thanks, I've already scanned this file...I'll have to look again...james
