[squeak-dev] Obsoletes...

Levente Uzonyi leves at elte.hu
Sun Dec 29 16:37:12 UTC 2013


On Sun, 29 Dec 2013, Frank Shearar wrote:

> On 29 December 2013 12:12, Tobias Pape <Das.Linux at gmx.de> wrote:
>> Hi all,
>>
>> I just took the todays Trunk image (Squeak4.5-13148#712) (NameVersion-Update#CIJob)
>
> Ah, that's nice & specific! Thanks! (Nit: we might as well not bother
> with update numbers, because our versioning is broken (*). The
> SqueakTrunk builds' TrunkImage artifacts will have an "update number"
> hundreds lower than a "full fat" image.
>
> (*) It's broken because an update number doesn't map in any meaningful
> way to what's in the image. "Update number" just means "the sum of all
> MC numbers of all packages in the latest update map that this image
> currently contains." If your Collections package is one ahead of trunk
> (because you have a local hack) while your Kernel package is one
> behind, you have _the same update number_.

The number only applies to Trunk images. There's intended to be only one 
of those (not two or three as it is now).

>
>> and ran
>>         SystemNavigation default obsoleteBehaviors
>> and got
>>         {AnObsoleteBlueSmallLandColorTheme . AnObsoleteSmallLandColorTheme . AnObsoleteSmallLandColorTheme class . AnObsoleteBlueSmallLandColorTheme class . AnObsoleteToolBuilderTests class . AnObsoleteToolBuilderTests . AnObsoleteBindingTest class . AnObsoleteBindingTest}
>>
>> We should fix that.
>> It breaks at least
>>         Smalltalk unloadReloadablePackages
>
> It also manifests as failing tests:
> * http://build.squeak.org/job/SqueakTrunk/712/testReport/junit/Tests.Release/ReleaseTest/testNoObsoleteClasses/
> * http://build.squeak.org/job/SqueakTrunk/712/testReport/junit/Tests.Release/ReleaseTest/testUndeclared/

One word: Environments.

>
>> What is the best way?
>> A postscript in a System Package change?

A postscript won't help, because new obsolete classes will be introduced 
because of Environments.

>
> I've been hoping someone would tell me! But Chris told us that the
> SqueakTrunk base image's state is a little broken, and that he doesn't
> see these tests failing. That would be well worth verifying. If so,
> the solution is to hand-roll another base image for SqueakTrunk. I
> have a candidate image that I've not quite finished preparing.
>
> As an aside, I think the reason the SqueakTrunk base image broke, at
> least in part, was caused by Nicolas and I adding new _necessary_
> packages to trunk. For instance, when I factored out
> ToolBuilder-Tests, the base image was told not to update packages it
> didn't have, so as not to reload unloaded packages (ST80, Universes,
> ...)... but that also meant it didn't get UpdateStream and
> ToolBuilder-Tests.

Using a smaller image to build back the full Trunk image doesn't fit the 
Trunk process.


Levente

>
> frank
>
>


More information about the Squeak-dev mailing list