[Gambas-user] Update ide Package module for shared libraries, Make installation packages to have preinst and postinst scripts

Brian G brian at westwoodsvcs.com
Sun Mar 8 15:09:33 CET 2020


I agree with gbwilly with his concern, But don't think I have been clear enough regarding
what I would like to see.

What I am talking about is allowing the major version number of the shared library to control the name of the package
to be changed such that their could be available to an application developer  multiple versions of the library.

This does not change the library name.

Nor would it at all change the dependency chain of your install package or older versions of the app being reinstalled 
as both versions would be available to resolve dependencies during the install.

Both

company.bogolib.1.0.0
and
company.bogolib.2.0.0 

Are available now, the original apps dependencies are unchanged and resolve correctly.

I don't believe you can link a libc:10 lib with a cc4 compiled and developed app and have it work correctly. 
But developers don't usually like the lib name to change, when the environment is updated.

I does in fact allow you to control the version of interface your application uses.

If you need your old app to use the old version of a library
don't change the major version number for that apps version of the library during bug fixes and changes. 

Update the minor version numbers of the library after the changes to it. That way you Stay compatible.

But when you release a updated version of your app that requires a lib with some not compatible changes to the interface 
enhancing the performance/ability etc then it is time to bump the major number and release the
app with the bumped interface number. 

This In fact allows your older version app to happily co-exist with the new one. And even be reinstalled. 
And future change and bug fixes to the library without issues. 

If in the future you would like your old App to use the new library for some reason then it is time to update it. 
In this case you are in fact releasing a new version of the app. 

So maybe its dependency chain should be updated.

Are All your shared libraries open source? 

I am not trying to make anyone's life more difficult here. I am only trying to smooth the over all development cycle and app redevelopment
cycle.

Also it allows the release of publicly available libraries with interface specs that can be changed and the app builder/designer can decide to upgrade
or not to the new super duper version of the library for his new release without compromising the existing installed or reinstalled base.

I really believe that this would be a useful and well used tool during the development and release cycle.

I have added the ability for the scripter to use only the major release number for shared libraries. Today I thought the ide had to select a specific
version of the library to link with. Maybe I don't understand well enough. Components don't care about the release information just the gambas version
but shared libraries depend on the release information in the ide.

As an aside, when we go to gambas4 with a different byte code for example, the shared lib for that version of gambas would get a major version bump.
but your gambas3 apps could still be used with the original library, etc.

Well that's my two cent from my many years in application development and system level development experience.

I would still like the change as originally asked for adding the major release number to the package name , not the library name.

Thank You
Brian G

----- Original Message -----
From: "Brian" <brian at westwoodsvcs.com>
To: "Gambas mailing list" <user at lists.gambas-basic.org>
Sent: Saturday, March 7, 2020 2:40:19 PM
Subject: Re: [Gambas-user] Update ide Package module for shared libraries, Make installation packages to have preinst and postinst scripts

I think I agree.

Thank You
Brian G

----- Original Message -----
From: "Benoît Minisini" <g4mba5 at gmail.com>
To: "Gambas mailing list" <user at lists.gambas-basic.org>
Sent: Wednesday, March 4, 2020 11:01:15 AM
Subject: Re: [Gambas-user] Update ide Package module for shared libraries, Make installation packages to have preinst and postinst scripts

Le 04/03/2020 à 18:57, gbWilly via User a écrit :
> Hi Brian,
> 
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, February 25, 2020 5:59
> PM, Brian G <brian at westwoodsvcs.com> wrote:
> 
>> The problem is that the name of the package changes like this 
>> westwood-testexec_7.14.9-0ubuntu1_all.deb 
>> westwood-testexec_7.14.8-0ubuntu1_all.deb 
>> westwood-testexec_4.14.7-0ubuntu1_all.deb etc
>> 
>> The package name is only considered to the first _ and the rest is
>> versioning
>> 
>> So no mater what major(also considered interface version for shared
>> libraries), minor, release number Debian deletes all older versions
>> and replaces it with the newer version. Applications depending on
>> the older version of the interface will now fail. If you try to
>> install the older version, it will tell you that the newest is
>> already installed.
> 
> This is exactly the behavior I want and I wouldn't like it to be
> different. I work a lot with Gambas libraries in a production
> environment.
> 
> My new library versions are meant to replace the older ones. Thing
> is, you make sure that your changes in the new library are backward
> compatible so they don't mess up the applications using them.
> 
> So that means for example that if existing methods get a new argument
> it is always optional. If I don't want that optional argument, I
> check all applications using this method (simple search in the IDE
> will do that), change them accordingly and redistribute them.
> 
> Pretty strait forward in my opinion.
> 
> 
>> I would like to propose that the major version number become part
>> of a library name as this
>> 
>> westwood-testexec4_4.14.7-0ubuntu1_all.deb
>> 
>> This allows the Major/Inteface number to control the package name
>> for libraries and therefore allow the development and
>> implementation in a production environment of newer versions of the
>> interface. and the slow adoption for older applications to the new
>> interface.
>> 
>> This change for Libraries to the naming
> 
> You proposition in my case would mean that a library would have a
> name + number added by the packager (say it is named MyLib) and the
> deb would be mylib1_1.0.1-0ubuntu1_all.deb My application (name it
> MyApp) would thus actually be dependend on MyLib1 (instead of
> MyLib). If I create a new major version of the MyLib package (deb
> would then be named mylib2_2.0.0-0ubuntu1_all.deb). So, I would also
> have to change the dependency in MyApp to make it work with MyLib2
> (instead of MyLib1). This to me is an undesired behavior, as that
> means I would always have to update all applications using a the
> library and redistribute them to make them work with the newer
> library.
> 
> If you really would like to work in this manner simply name your
> library with the added major version number. So name your first
> version MyLib1 being version 1.0.0 Every update within 1 version (so
> 1.0.1, 1.1.20 etc) you stick to the name MyLib1
> 
> Once you go to a newer major version that is no longer backward
> compatible name the library MyLib2 (being version 2.0.0, 2.0.1,
> 2.1.20 etc.) Older applications depending on MyLib1 will not be
> bother by the MyLib2 update as the libraries are considered by the OS
> as different packages (since they have different names). Both MyLib1
> and MyLib2 will live alongside each other and older applications
> would need to be refurbished and redistributed to make them work with
> the major version 2 of your library.
> 
> This way the default expected behavior of how packages and
> dependencies work in a Debian/Ubuntu environment would still be met.
> 
> Just my two cents,
> 
> gbWilly
> 

I mostly agree with you... What I could do is adding an option that add 
the major version to the project name when making the package. But the 
simpler is what you say: put the major version directly in the project name.

Regards,

-- 
Benoît Minisini

----[ http://gambaswiki.org/wiki/doc/netiquette ]----

----[ http://gambaswiki.org/wiki/doc/netiquette ]----


More information about the User mailing list