[Cuis-dev] Packages Held Back

[ken.dickey at whidbey.com]

Greetings all,

Well, I have tried a number of experiments and now better understand the 
scope of the problem.

In short, the solution I was reaching for will not work.

The basic problem is that the directory structure for packages must be 
disjoint for held back packages as the (default) search strategy for 
Package Requirements may find a wrong version to load. [Details at end, 
below].

Hilaire's suggestion that we fork packages in GIT may be the simple 
solution.  The detail to be worked out is how to obtain the collection 
of packages matched with the released Stable images.

I know that it is possible to have GIT (sub)repos which can be cloned 
via `--recursive`, but I am certainly out of my depth here.

The germ of the idea is to create a git Branch for each package "held 
back" for a particular release and have a Stable repo reference the 
branch for that version.

An alternative idea would to Fork and have a Stable repo refer to the 
forked package(s).

Mumble..
-KenD
/===========================================================/
On 2024-05-31 06:25, ken.dickey--- via Cuis-dev wrote:
> On 2024-05-30 21:57, H. Fernandes wrote:
>> It may just be safer and simple to work with different cloned
>> repository then fetching into the matching packages with appropriate
>> mean (git tagged version or branches).
> 
> We have not yet made use of the Maximum Version on FeatureRequirements.
> 
> I need to update the search to keep looking when the package Provides
> cuis-base version is too old, at which time the strategy I suggested
> will just work.  I hope to do and test this in the next couple of
> days. I will get the code and test out for my proposal.
> 
> One topic we might touch upon at the end of the Cuis meeting -- if 
> time.
> 
>> With each cuis stable release we could have a file with the
>> appropriate tag or name to search in git for compatible package.
>> 
>> I don't know well git to know how this could be done on the must
>> simple efficient way.
> 
> Nor I.  But I know better how Cuis works!  :)
> 
> -KenD
/===========================================================/

Addendum: How I convinced myself the simple solution would not work -- 
by example.

I have Cuis-Smalltalk directory which contains various packages 
including Cuis6-2 and Cuis7-0.

The attached PkgTest.tgz can be untarred in the Cuis-Smalltalk 
directory.
[cd Cuis-Smalltalk; tar xvfz <wherever>/PkgTest.tgz].

This will yield a EmptyStuff directory in Cuis-Smalltalk with two 
packages.  RequireEmpty requires Empty but updated for Current/7.0.

Also, an Cuis6-2/HeldPackages6-2/EmptyStuff directory where package 
RequireEmpty required the Empty package but with a cap to pre-7.0 
Cuis-Base.

If you bring up the 6.2 image and `Feature require: 'RequireEmpty'.` in 
a Workspace, the held back version is found and all loads as expected.

If you bring up the 7.0 image, `Feature require: 'RequireEmpty'. yields 
a popup complaining of the wrong base image.

If you use a FileList, look at the file 
Cuis-Smalltalk/EmptyStuff/RequireEmpty.pck.st all loads OK.

What is going on here?

The answer is that within the 6-0 release, the HeldBack6-0 directory is 
more local and  always searched first, so the held back package is 
always found.

In the 7.0 release, the search within the Cuis-Smalltalk sub-directories 
searches child directory "Cuis6-0" _before_ directory "EmptyStuff".

So in the 7.0 image, `Feature require: 'RequireEmpty'` finds the 
RequireEmpty package in Cuis6-2/HeldPackages6-2 which has the wrong/old 
version, but looking in the FileList at the rightly versioned 
RequireEmpty.pck.st, the search ignores the old/wrong Empty.pck.st and 
picks up the right one.

Basically this means that unless the directories to be searched are 
disjoint, it is quite easy to pick wrong package versions -- an possibly 
not even be aware of it.

Simple ideas do not always work.

HTH,
-KenD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PkgTest.tgz
Type: application/x-gzip
Size: 723 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240601/2f49d159/attachment.bin>