<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>My question stands, who decides what is big enough to be candidate to be<br>separately packaged? If they were 13 methods but 2 classes they will be<br>integrated packaged in squeak trunk? What about a class with 400<br>methods? This is subjective?<br></div></blockquote></div><br><div>Hi Miguel,</div><div><br></div><div>this is something I have been working on for the Cuis - InstallSeries project. While "InstallSeries" installs packages/updates/changesets aka slices, the converse "System-Packaging" project allows you to define a small slice, and export it as source, like so.</div><div><br></div><div>=========</div><div><div>PackageStartUpManager-#slice1SystemStartupManagerLaunch</div><div>"</div><div>Launching from the initial script, and accessors for command line arguments.</div><div>"</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>self write: 'updates1-System-Support/0001/StartupManager-(launch)' using: [ :pkg |</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>pkg stampComment: self myComment.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> <span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>pkg requiresClass: StartupManager interface: #( ).</div><div><br></div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>pkg systemProtocol: 'system-startup-launch'.<span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>]. </div></div><div>========</div><div><br></div><div>This particular slice definition currently covers 8 methods.</div><div><br></div><div>It exports the code from my working Sooty2.1 image (Cuis2.1 + lp:~/keithy/cuis/stable-kph), from where I commit it to the shared repository for others to load via the "InstallSeries" mechanism.</div><div><br></div><div>I am in the process of working out the finer details of how this all works in a non MC world. So far I am able to replicate many of the use cases that would previously have used a substantial chunk of the functionality of Installer, MC1, Sake/Packages or Metacello, Gofer, ChangeSorter, MC2(?) All this for just 5 core classes give or take. </div><div><br></div><div>For example, I can organise for a complex image to be built from Magma Seaside3.0, Pier and Beach packages, with a load order taking in to account dependencies. I can share this "branch" for you to load exactly into your base image whatever it may be, merging in any of your own patches you may wish to add for your context. At any point I can re-export all of the source code for my branch to commit back up to a shared repo as a one liner. </div><div><br></div><div>regards</div><div><br></div><div>Keith</div><div> </div></body></html>