Jeremy Katz wrote:
On Tue, 2007-09-04 at 16:47 -0500, Douglas McClendon wrote:
> Mark McLoughlin wrote:
>> On Mon, 2007-09-03 at 15:33 -0500, Douglas McClendon wrote:
>>> Mark McLoughlin wrote:
>> What you have is mostly fine IMHO, it was the tarball I had a problem
> Ok, in that case, it should be no sweat (relatively) to put together a
> new version of the patch, updated against the 30+ commits seen since the
> last version, which uses dumpe2fs in anaconda, no tarball, osmin.img
> truncation, and setting loops and dms to readonly where possible.
> But, before I do that, can I get feedback from one other person,
> preferably who has commit authority, to tell me that this will be
> committed? Jeremy, you mentioned objections in the past? (all my
> goading of said objections, was because I was so sure that there is no
> remotely more correct way to accomplish the task, and I would be
> genuinely entertained to be corrected on that fact)
I think that some of the above will go a long way towards making things
look nicer which is going to make me more amenable to it. I still don't
necessarily _like_ it because I still think that it makes anaconda
depend a bit too much on a lot of the details; but I guess as long as it
can fall back cleanly in the absence of the bits, that just means a
larger testing matrix.
I'm going to assume that that was a "yes I like what the code does, yes
it will be applied"
As far as the larger testing matrix- If you go by my suggestion, which
markmc echoed, and make it the default path (along with removing the
--ignore-deleted option in favor of it being default), then the testing
matrix will be the same.
The only reason I offered --turbo-liveinst and --cleanup/ignore-deleted
as options was to ease their acceptance. I really believe that they are
the 'one true way' and that there is no benefit gained by having the
original code path as an option. As you said, it just means a larger