Miguel's suggestions look okay. Seaside has a slightly different naming 
convention (http://code.google.com/p/seaside/wiki/PackageNaming) that 
looks like the following:

MagmaClient-Core
MagmaClient-Squeak-Core
MagmaClient-Pharo-Core

MagmaClient-Tests-Core
MagmaClient-Tests-Squeak-Core
MagmaClient-Tests-Pharo-Core

Dale

On 04/15/2011 12:51 PM, Miguel Cobá wrote:
> This may help
>
> http://code.google.com/p/seaside/wiki/PackageNaming.
>
> Also, if you are repackaging Magma, it would be marvelous to eliminate
> whitespace from names, if possible.
>
> e.g.
>
> MagmaClient-Core
> MagmaClient-Squeak
> MagmaClient-Pharo
> MagmaClient-Tests-Common
> MagmaClient-Tests-Squeak
> MagmaClient-Tests-Pharo
> MagmaServer-Core
> MagmaServer-Squeak
> MagmaServer-Pharo
> MagmaServer-Tests-Common
> MagmaServer-Tests-Squeak
> MagmaServer-Tests-Pharo
>
> Of course most those packages are almost never needed and will be only
> created if needed to do something different for a given platform that is
> used by upper layers. But you get the idea.
>
> El vie, 15-04-2011 a las 14:24 -0500, Chris Muller escribió:
>> What is the best-practice for structuring a collection of MC packages
>> containing for platform-independent portions?
>>
>> For example, I currently have "Magma client' which has code specific
>> to Squeak.  So I made a new package:
>>
>>    Magma client-Squeak
>>
>> And then renamed the method-extension category from "*magma client" to
>> "*magma client-squeak".
>>
>> Unfortunately, PackageInfo considers #isYourClassExtension: to be true
>> even if only the "core" package name matches the _prefix_ of the
>> extension category name ("*magma client-squeak"), causing those
>> extensions end up in two packages; "Magma client" as well as "Magma
>> client-Squeak".
>>
>