[gobolinux-users] New user question (start of many)

Carlo J. Calica carlo at calica.com
Thu Nov 11 05:26:07 GMT 2004


Hisham Muhammad wrote:

>On Wednesday 10 November 2004 20:08, Carlo J. Calica wrote:
>  
>
>>Hisham Muhammad wrote:
>>    
>>
>>>On Monday 08 November 2004 17:47, Rohan NIcholls wrote:
>>>      
>>>
>>>>Hi guys,
>>>>
>>>>I am a brand new user of Gobo linux, and am loving it.  In my travels
>>>>a number of questions have come up.
>>>>
>>>>1. Is there some way to upgrade the whole system?  I tried executing
>>>>UpgradeDistro but:
>>>>        
>>>>
>>>Oh, this was an "undocumented feature" we never got to the point of
>>>implementing. The idea was that, when we get to the point to have
>>>something that upgrades the system automatically, we can post the script
>>>and the existing systems would be already "upgrade-ready".
>>>      
>>>
>>I've been giving this some thought.  Wouldn't it be better to "tie" the
>>version of the system with the version of Scripts.  We can also use the
>>"UpgradeDistro" script as documentation for the fs heirarchy.  The
>>Goboify script that Rafael mentioned could form the basis for this.  A
>>usage example is moving a 006 system to current.  We've moved a few dirs
>>around in /System/Kernel, added some in /S/Links.  The UpgradeDistro
>>script would assert those dirs and move things around.
>>    
>>
>
>Correcting myself: UpgradeSystem _was_ in fact implemented by André for 011. 
>(Rohan's download failed because of the recent server move). It was a 010 -> 
>011 upgrade script, announced on the list. (Didn't attract much attention, 
>IIRC). It did exactly what you describe: apply the structural changes on the 
>system. Actually, I think even a 007->010 existed, implemented by Guilherme 
>(not integrated in the Scripts package, though).
>  
>
Yes, I remember that.  It would be nice to return to that and extend it 
further.  This script is an excellent tool for documenting the changes 
through time.  Defining a few functions for common operations 
(assert_dir, move_dir) and checks (version comparisons), package 
installs (upgrades and additions to base).  Adding the goboify script 
documents the bootstrap process.  Need to define a starting point, (011 
would be fine) and keep it going.

>Well, the version of Scripts used to be tied to the version of the system, but 
>then most of the time the "latest stable version" would be a development 
>snapshot, indistinguishable from, well, unstable snapshots. Our decision to 
>change the version numbering was so that versions and snapshots are more 
>clearly identified; especially since the "Scripts maintainer token" tends to 
>pass from hand to hand (it was with André for a large part of the year, it's 
>with me again now), so by looking at the "date-name" snapshot identifier it's 
>not a clear indicator on how official a version is. In the early days that 
>didn't make much difference to distinguish between versions and snapshots, 
>but now it makes sense.
>
>As to why the major number doesn't match the distro release; we decided to use 
>the major number to indicate "major development branches" in all 'GoboLinux 
>apps'. There are no plans in the horizon to branch out a Scripts 3 tree. The 
>Compile 2 tree is under a slow, but carefully planned development (Compile 1 
>is doing well, I think, so there's no hurry). Snapshots are posted to 
>gobolinux.org/snapshots (directory listing is disabled as I write this, but 
>will probably be already fixed as you read this :) ). [btw, not much to see 
>on Compile 2 now, except for some preliminary modularization work.]
>  
>
The newer x.y.z.date-name based snapshots are a great improvement.  
There is also the difference between system version and distribution 
release.  The dist release happens regularly and contains the newest 
applications.  This is different than the system version.  That defines 
the fs.  I'm suggesting a tie between Scripts and that version.  To 
avoid problems, it can be 2.1.  Any changes (moving /S/Kernel around or 
adding something /Files) would cause a change in the major/minor 
number.  A corresponding change to UpdateSystem would enact/document 
it.  This version would be saved somewhere for later upgrades.

This separates the release version and which is nice since the system is 
must more stable. 



More information about the Gobolinux-users mailing list