|
|
|
|
|
|
by igouy
31 days ago
|
|
|
> … the point of a reproducible build is to verify that the binary i use, or that the package i use is based on the same source that i have. I have been talking about how to reproduce a particular build, not how to verify. From the same initial state, perform the same sequence of actions, implies arrive at the same final state. Reproducible. "Retaining your old change logs gives you a record of all the changes you have made to the system. This will prove invaluable when you receive a new release of Smalltalk/V.
… In short, back up the image and change log together, and you shouldn't have any problems." page 285 Smalltalk/V 286 Tutorial and Programming Handbook 1988 |
|
|
so we actually have to go back to this question:
> traditional way of doing smalltalk development
Is that in-conflict with a reproducible build process or can we have both?
to summarize, i was talking about traditional meaning to make changes in an image and then exporting them if needed. and then i was wondering if local changes and the base image can be kept separate, and by that i meant "within the image" so that, when you look at an image, or when you use it, browse the code, you can easily see what are changes and what is the base image. kind of like in an operating system where i can clearly distinguish system files from user files. so effectively that would suggest some kind of ownership markers, or, alternatively, it needs versioning of objects within the image.
i am not suggesting that smalltalk needs to be changed, but i am trying to work out the limitations that affect the workflow. essentially, because this distinction is missing, there is no way to reproduce a build (in your sense of the meaning) without exporting the code and re-importing it in a new image. actually, object versioning within the image would be a really useful addition to smalltalk. it would allow you to easily go back to old versions. of course it would also cause the image to grow, so there would have to be some efficient way to store that. for one, old versions don't need to be kept in memory so they could be in a secondary storage. or put differently, smalltalk could keep track of the changes in the changes file as it does, but in such a way that i can browse and load in old changes from within the image. i don't know if that is possible now.
the image based server system that i talked about earlier btw does have an ownership system and object based versioning. that reveals some interesting potential.
btw this lack of distinction between base image and changes in the image, especially the lack of ownership information i believe is one reason why linux distributions didn't pick up smalltalk as soon as it became available under a free license, because the license could not actually be verified across all objects. especially older objects that had the source purged to save space.