Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] ISO generation

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Laurent Wandrebeck" <low AT low.ath.cx>
  • To: afrayedknot AT thefrayedknot.armory.com, sm-discuss AT lists.ibiblio.org
  • Cc:
  • Subject: Re: [SM-Discuss] ISO generation
  • Date: Wed, 26 Jan 2005 19:55:01 +0100


Le 26/1/2005, "Andrew" <afrayedknot AT thefrayedknot.armory.com> a écrit:

<big snip>
>I would have to say its a better approach for the long term to have
>our software be modular so that architectural differences can be
>encapsulated in those modules and configuration data. Then the higher
>level tasks can be driven by configuration details to use whatever pieces
>of modular code are necessary. In the end, the modular approach becomes
>less complex than the more monolithic approach of having everything in
>one script for "ease of maintainence".
<snip again>
AFAIK, right now, sorcery is some kind of modular (archspecs etc).
But, some arch (sparc, amd64, em64t, and maybe others i don't know of)
need a particular path for {bi|multi}-arch support. Do you think it is
possible to make it modular ?
My very little knowledge of sorcery would say no, but you are for sure
the one that can give the right answer.
If it isn't possible, then what to do to support new arch ? I see three
solutions:
1st would be to integrate {bi|multi}-arch support into sorcery. So, it
satisfies everyone.
2nd would be to maintain several branches, increasing work load in an
already too small team.
3rd would be to refuse {bi|multi}-arch integration, making about 10 people
prolly unhappy.
Of course, having pure 64bits ports would be some kind of a solution, but
some software programs won't run in 64 bits mode, and no one can say when
they will. Quite annoying.
If making {bi|multi}-arch support modular is easy, then forget what is
written above ;)
Regards,
Laurent.




Archive powered by MHonArc 2.6.24.

Top of Page