On Wed, Jun 16, 2004 at 08:49:16AM -0500, Brian Elliott Finley wrote:
> Thus spake Jerry DeLapp ([EMAIL PROTECTED]):
> >Q: The current spec file has a bunch of 'migration' code in the pre/post 
> >scripts.  I'd like to rip that out and put it into the documentation 
> >instead.  The reason is that Fedora has a stated policy against RPMs that 
> >do terminal I/O. I'd like to conform to that.  I'd also like to tweak it 
> >to respect any relocation information in systemimager.conf.  Objections?
> 
> Dann?

Sure, I'm ok w/ removing noise, but I vote to maintain the
upgrade code since I still expect some people to be upgrading from 2.x.
There's people that have had no reason to upgrade yet; but will at some
point in the future.

> >Q: The current spec file builds a package named 
> >systemimager-i386boot-standard. The kernel in that package, however, is 
> >compiled for i486 (i586 in 3.2.0).  

Yeah, i fixed that in 3.2 cvs, so 3.2.3 will use 486; it doesn't affect
kernel size, and I'm sure there's still some 486 boxes around used in
classroom installations.

> We've had at least one bug report 
> >related to that.  Should I tweak the spec file to change the name to 
> >reflect the kernel architecture rather than the build machine's 
> >architecture? 

i386 is used to describe the architecture, not the subarch - though
maybe something like x86 would've been a more appropriate choice.

> I'm thinking we may need this RSN for native 64-bit support. 

we have 64-bit support, but i'm guessing you mean x86_64 - that's
a different architecture (not a subarch), so that isn't an issue.

> >Q: Do we care about i386 any more?
> 
> Technically, no.

gcc has dropped support for it so i don't think its feasible
to support it.

> 
> >Q: Do we want to have more than one kernel arch boot image (e.g. 
> >486,586,686)? This would probably require tweaks to the make rules.
> 
> No.  The 486 kernel will work fine on any higher architecture, and for
> the special purpose application we use it for, there's no significant 
> downside either.

agreed.

> So it looks like our options are:
> a) keep it as i386boot, and explain in the description (rpm -qi) that the
>   i386 refers to the kernel name for that architecture, as opposed to
>   it's hardware optimization, and that it was built for 486 and higher
>   level systems.
> b) change it to i486boot, and all the ripple effect in the code and
>   path naming that that would imply.
> c) change it to ia32boot?  still explain in description that it's for
>   486 and higher
> 
> I'm kinda leaning towards a).

the name i386 is calculated in various places in the code - the install
code needs to know where to put the files on the server, the client code
needs to know where to look on the server for them, and all of the 
mkautoinstall* tools depend on it.  so, i'd agree w /a).



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Sisuite-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel

Reply via email to