John Levon wrote:
> On Mon, Apr 06, 2009 at 11:35:26AM -0400, Dave Miner wrote:
> 
>>> I don't think "boot/amd64 is icky" is a strong enough argument for
>>> purposefully leaving this broken.
>> To clarify, the reason why it's somewhat loathsome is that it's more 
>> stuff that is in non-standard places and has to be handled specially by 
>> live CD installs.  Using the standard locations, it gets cleaned up 
>> automatically by bootadm.  It also reduces the amount of divergence 
>> between the live CD and the installed system, which is a goal of the 
>> live CD architecture.
> 
> I'm bemused: before the gate closed, the goal was to keep the paths the
> same across all architectures. Now it's to be the same as the installed
> system?
> 

The goal there was to not be ISA-specific and use the standard names, 
but the change was clearly incomplete in terms of not re-locating to 
standard paths, which I had suggested in one of the conversations before it.

> Can you expand further on what problems are caused by keeping the path
> the same as it was? Is there some significant amount of code or special
> handling needed (pointers would be great) ?
> 

They aren't hard problems, they're just changes in additional places to 
ensure this is cleaned up properly, rather than deleting a couple lines 
of code and letting the existing system architecture solve the problem 
for me.

>> The user base that are broken are sufficiently limited at this point 
> 
> I don't think it's possible to make that assertion as 2009.06 has not
> been released.
> 

OK, fair enough.

> It just doesn't make sense to me to purposefully introduce bugs for some
> vague benefit. /boot/boot_archive was presented as fait accompli, but
> now we have a chance to not break compatibility - I'd hope that such a
> choice is backed up by some very good reasons.
> 

That change had been in for two months before the issue was raised at 
the code freeze deadline, due to obvious lack of communication and test 
coverage that we've already discussed.  This thread is part of ensuring 
we don't do that again.

 From my point of view, the simple reason here is that the path chosen 
originally was just some hacking around that Moinak did; we never got 
around to rationalizing it until 5787 and didn't do it quite right. 
Were we following normal processes of ARCing before shipping products, I 
wouldn't expect /boot and /boot/amd64 to fly, given we already have 
established namespace in /platform for the exact purpose (somewhat 
ironically specified by direct boot).

None of this is hard.  I simply am not that motivated by compatibility 
with 2008.11 on the expectation that most users of it would seem highly 
motivated to update.  The time to clean up inconsistent turds is now, 
before we are stuck with them for many years as the support horizons expand.

Dave

Reply via email to