Creating a Symlink for Perl

[Jasper]

Hi there

I compiled a newer build of Perl to use with Fossapup64.

When I look at my current build I realise that Perl is symlinked to Perl5.30.

What do I need to do to get Perl to link to my updated version?

I would like to use this as a SFS instead of installing it if possible as the installation files are approximately 62mb.

[Jasper]

Would this work?

[williwaw]

it may not if the directory does not have the same path as it will when mounted as a sfs

[Jasper]

@williwaw

Thanks for the answering my query.

I thought that a Pet file would overwrite/add new files to the OS?

For Perl to be executed the existing file should call on the new files?

So in this instance, would I better off removing the built in Perl application and then install my updated version?

Then create the symlink as demonstrated?

So, I might not be making much sense in my message....... but I do have picture of what I would like to do.

**EDIT**

The "Puppy" directory is on a different partition which contains files I have been working on.

[Jasper]

I did try it but it failed to work

[Jasper]

This is the compiled application:

**EDIT** Removed link

It does not work within Puppy as it is not able to be executed.

[williwaw]

do you have a new perl pet, or just the files you want to subsitute?
making a sfs of the files might complicate things tho... but you could implement a script when you wanted to load the sfs.

schematically, I would
1. run mksquashfs on the new directory
2. locate the resulting sfs to where ever you intend to keep your sfs's
3. write a script that when clicked, would
a. load the sfs, then
b. create the new link /usr/bin/perl that points to the new executable in the sfs.

it would overwrite the existing link, so I would also

4. create another script that would also create a different new link /usr/bin/perl that would point to the target of /usr/bin/perl as it stands now, ie you could restore the original configuration when the sfs is not loaded

just saw your new post,
look at this while I look at that

[Jasper]

@williwaw

Your instructions are invaluable

Looking at my new build, I am missing a file that is present in my OS.

I might have another attempt to compile it and check any options I may have missed which hopefully will provide the x86_64 binary file

[williwaw]

I did try it but it failed to work :(

you failed to remove the built in from the puppy.sfs?
that might not be a bad thing if the proposed substitution schema has any potential.
you would not have to make the sfs from the new perl if that makes things easier
my proposal is more like a perl portable, really

[Jasper]

@williwaw

Yes, I did not remove the built-in as I was unsure.

I had another stab at compiling the application and did end with some errors. One of them I am not to fussed about as it simply opens up my browser to view the online Man page.

I should have kept my build instructions for last time

Need to check this again

Code: Select all

./Configure -s -D symbol -D symbol=Duse64bitall symbol=Dusethreads -Dprefix=/usr -Dcc=gcc

Thanks again

[Burunduk]

The reason why your perl is still 5.30 is in the layered filesystem used by Fossapup and many other pups. (You may want to read an overview in the /initrd/README.txt file.)
Loading your sfs makes a new layer that is below the existing ones. So /usr/bin/perl symlink in your sfs is shadowed by the one in the main sfs above it that points to perl 5.30. If you create this link after the sfs is loaded, it will be in the writable layer (and later in the save file or folder) on top of other layers and will work. But when you unload your sfs, this link remains and is broken. So it should be created and then removed every time. The same thing happens to other files in your sfs if they have the same name as the existing ones.
It would be better to put your new perl in its own directory somewhere in /opt or /usr/local But it will be still necessary to create/remove the symlink to it.

[Jasper]

@Burunduk

I am embarrassed but readily admit I have not fully understood how SFS work especially regarding layers and their priority.

I believed (for no explainable reason) was that once the base SFS was loaded, the application SFS would sit above and finally my Pupsave would be the top layer.

Now correct me if I am wrong ............ the DevX SFS contains the compiler applications and other resources like Git. Therefore this should have no affect on the earlier layers.

I think I have made this all up in my own mind and not through some divine inspiration

[Burunduk]

once the base SFS was loaded, the application SFS would sit above and finally my Pupsave would be the top layer.

Loading an application sfs below the main sfs may break the application (for example, when old libs from the main sfs are used). Doing it the other way around may break puppy. It seems the former is less evil.

There should be a utility somewhere in this or old forum that can load an additional sfs above the others. But I think it's not a good idea to have several versions of a program in the same directory on different filesystem layers. Files get intermixed and the program may not work. It's better to place a new version into a separate directory or replace the existing one (remaster one of the puppy sfs files) Note, however, that a new version may be incompatible.

[Jasper]

@Burunduk

Why I came to my conclusion was that I attempted the same thing with another application which works perfectly for me.

The first terminal is when DevX is loaded.
The second terminal is when I add my updated Cmake.

I did this as I need to compile an application which required a newer build.

I had hoped the same could apply to Perl.

I guess I really do need to read up more about this before progressing forward.

Thank you again.

[Burunduk]

This small script may be useful when many sfs files are loaded. It prints the current aufs stack starting with the top most layer. It's only tested on my Fossapup64 9.5 The aufs sysfs description I've found here.

Code: Select all

#!/bin/bash

# auls - print puppy aufs stack

sysfs=/sys/fs/aufs
[ -e $sysfs ] || { echo "AUFS not found."; exit 1; }
cnt=0
list=''

for f in $(find /sys/fs/aufs/ -regex '.*br[0-9]*' | sort --sort=version); do
  let cnt+=1
  mnt=$(findmnt -n -o TARGET,SOURCE `sed 's/=.*//' $f`)
  bak=$(losetup -l -n -O BACK-FILE "${mnt##* }")
  list="$list$cnt. $mnt $bak"$'\n'
done

[ ! -t 1 ] && gxmessage -title "AUFS Stack" "$list"
echo $'AUFS Stack:\n'"$list"