Jeremy Katz wrote:
On Mon, 2008-05-12 at 19:51 +0200, Joel Andres Granados wrote:
The argument of waiting for pyparted to be rewritten is a considerable one. If your
going to do the whole thing from scratch, why bother adding new stuff to the current
one. OTOH, checking for the validity of the partition so in the anaconda code make
me feel dirty. The other thing is that fix to anaconda goes in and then might stays
there even when the new pyparted is being used. It might be good to do the anaconda
change and have a bug (if someone has a better idea of how to not let this fall
through the cracks please tell me) that documents this issue.
The anaconda change won't remain if we change the pyparted API. There
are cases (including extendeds, iirc) where getting access to the
non-active partitions is important so you can't just go changing the
semantics of the API call. If you control all the code up and down and
there aren't any "public" APIs exposed, then sure, you can change
semantics whenever -- but that's not the case here.
I agree with you. What I propose is not a change to the old API but an change to the new one before it gets out the door. We can have a function that has an argument "validonly" (or something like that) which is false by default. This would mean that the call will have the argument only when the caller wants to ensure a valid "next partition". In other words:
nextvalidpartition = next_partition(validonly=true)
nextpartition = next_partition()
my point being that the check for the validity of the partition, IMO, is better put inside pyparted and not in a higher level. This does not change the semantics of the current calls. the next_partition() will still work and will still return the next partition, valid or invalid. So stuff that uses that function will not be invalid after the change. It does change the semantics of the calls where we want to ensure that the next partition is valid, it additionally does away with the couple of lines that check for the validity.
--
Joel Andres Granados
Red Hat / Brno, Czech Republic
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
