[Solved] lua 5.4.6 for TCL14 x86_64

[GNUser]

Final set submitted. Timestamp is 2023/08/19. GNUser out!

[Rich]

Hi GNUser

... Rich, please mark thread as solved. ...

Done. 

[Juanito]

1) Regarding the startup scripts, wouldn't it be better for it to link the unversioned file to the version in that extension? Like this:

* lua-5.3.tcz forcibly links /usr/local/bin/lua to /tmp/tcloop/lua-5.3/usr/local/bin/lua5.3
* lua-5.4.tcz forcibly links /usr/local/bin/lua to /tmp/tcloop/lua-5.4/usr/local/bin/lua5.4

Same idea for lua.pc and liblua.so.

I suggest we remove lua-5.3-dev and lua-5.3 so that only the latest version (5.4.x) will be built against

[CardealRusso]

I suggest we remove lua-5.3-dev and lua-5.3

This is both convenient and dangerous, as many 5.3 libraries are incompatible with 5.4.

My only doubt is why they want to try to make it compatible to have 2 versions simultaneously loaded, a very inconvenient, problematic and unusual practice.
Having two separate versions without using tce.installed seems to be enough. Furthermore, it would be very annoying to have to type "lua5.4" instead of just "lua".
(I didn't follow the entire thread, so I may have missed some important information.)

[Juanito]

I didn’t say that lua-5.3-lib would be removed.

[GNUser]

In the 5.4 set of extensions I submitted for x86_64, I manually added version numbers to files that are normally unversioned (e.g., lua manually renamed lua5.4) and created startup scripts that create links (e.g., lua linked to lua5.4). If every version set were to do this, different versions could coexist in the repo and could even coexist loaded on the same machine.

The point of the thread was to pick your brains for ideas on how to make different Lua versions coexist, under the assumption that it is necessary or at least convenient for TCL to support more than one version at a time. If it is neither necessary nor convenient , I'm completely fine with scrapping the idea and just supporting vanilla build (with patch for shared libraries) of latest version. I 100% defer to Juanito on the question of necessity and convenience.

[GNUser]

Maybe the simplest, most TCL way:
* keep complete vanilla set of current version (lua-5.4.tcz, lua-5.4-lib.tcz, and lua-5.4-dev.tcz)
* keep only *-lib.tcz of old version (lua-5.3-lib.tcz) because some repo applications need it

Juanito, if you decide to go with this approach, the lua-5.4.tcz already in x86_64 repo (timestamped 2023/08/17) should be fine. Please let me know if you want me to resubmit lua-5.4-lib.tcz and lua-5.4-dev.tcz built with the LFS patch, without any manually renamed files or startup scripts.

I guess the last detail would be to remove liblua.so from lua-5.3-lib.tcz, so that applications compiled in the future don't accidentally compile against the old version of the library.

[Rich]

Hi CardealRusso

... My only doubt is why they want to try to make it compatible to have 2 versions simultaneously loaded, a very inconvenient, problematic and unusual practice. ...

Sometimes when an extension gets updated it causes other extensions
to break. If a lot of extensions are affected, a renamed copy of the old
extension may be left in the repository to deal with the breakage. Both
copies can be installed and co-exist.

Some examples from TC10 x86 include:

Code: [Select]

ncurses5.tcz
ncurses.tcz
libffi5.tcz
libffi.tcz
libpng12.tcz
libpng.tcz

[GNUser]

Hi Juanito.

I suggest we remove lua-5.3-dev and lua-5.3 so that only the latest version (5.4.x) will be built against

Sorry, I missed this. Okay, I understand that this is how you wish to proceed. In that case, I will send later today a vanilla set of 5.4 extensions for the TCL14 x86_64 repo (tagged 2023/08/20).

Do you agree that liblua.so should be removed from lua-5.3-lib.tcz? I learned recently that the extension manager does not overwrite existing files. Therefore, if lua-5.3-lib.tcz is loaded (e.g., because an application needs it) and user later loads lua-5.4-dev.tcz and lua-5.4-lib.tcz to build something, the old liblua.so will not be overwritten and will still be pointing to liblua.so.5.3.6

[aus9]

GNUser

Forgive my suggestions and comments below.
There may be an opportunity for you to submit a TCE with an install script that deletes ram drive files so that no matter which package is loaded first,
the "new" TCE populates the ram drive.

Let me give some examples from an idiot I know too well. In my early days, I would click in Apps GUI and leave the download option as "OnBoot"
and might end up with a boot list that is actioned from top to bottom
TCE-Z.tcz
TCE-A.tcz

such that the the shared object/executable/some config from Z populates the ram drive and A never gets a chance to grab those spots.

And....I can not stop a member from having accidently added TCE-Z to their boot list
but I can create an install script (for TCE-A) that deletes any current ram drive files and re-populates the ram drive with files from A.

so for other members who can "half" follow me, we have 2 examples
someone loades TCE-A then TCE-Z  or TCE-Z then TCE-A

If TCE-Z is the unloved TCE and populates the system files, TCE-A does not grab those slots unless you have an install script for system file deletion
If TCE-A is the loved TCE and grabs the system files, as long as TCE-Z has no install script ..(that deletes any system files)..we are good to go.

I hope that makes sense?