installing packages requiring apt-get

[courtage]

I often come across packages that don't offer a download of a .deb but instead simply give instructions for apt-get.

Which is fine if you have apt-get but of course these days puppy uses pkg, and while pkg is clever and powerful, it isn't apt-get.

So my latest frustration is protonmail's VPN, with these instructions:

Code: Select all

1. Get the ProtonVPN repo setup DEB package

Download the ProtonVPN DEB package

2. Install the ProtonVPN repository

Open a terminal and run the following:

sudo apt-get install {/path/to/}protonvpn-stable-release_1.0.1-1_all.deb
3. Update the apt-get package list

Enter the command:

sudo apt-get update
4. Install the ProtonVPN Linux CLI

Last step! Type this command:

sudo apt-get install protonvpn-cli

(that they allow you to download one .deb but then force you to use apt-get for the next is intensely annoying but not a puppy problem!)

This is in bionic64 btw

It would be helpful to have a wrapper for pkg that made it work seamlessly with apt-get commands.

anyway.

[rockedge]

There is a way in Fossapup64 to add in a fully functional APT using a WDL_GO plugin from wiak. It is an SFS module loaded after setting up a Fossapup64 which will provide all the parts needed.

Screenshot(7).png (99.96 KiB) Viewed 8965 times

[mikewalsh]

@rockedge :-

Where do we get this plug-in from, Erik.....for those of us not running WeeDog? Is it compatible with 'standard' Fossapup64?

Mike.

[rockedge]

@mikewalsh Here is a link for the apt_sfs_load_fossa_amd64.sfs which is written by wiak.

Start with a fresh Fossapup64 and I place the sfs into the frugal install directory with the rest of Fossapup64.

BEFORE LOADING SFS use ROX to locate and duplicate these 2 files:

Code: Select all

cp /sbin/init /sbin/init-puppy
cp /sbin/poweroff /sbin/poweroff-puppy

I also have the devx and 32 bit compatibility sfs's loaded.

now I load the apt_sfs_load_fossa_amd64.sfs by clicking on it. (SFS-Load-on-the-fly works as well to load)

Important tip
Once the apt module is loaded and update and or upgrade is run it is possible that apt will over write 3 components crucial for Puppy Linux to reboot or shutdown cleanly with systemd parts. This is why we copied the files above.

these 2 scripts will also help understand what needs to happen occasionally:
restore_puppy_boot.sh

Code: Select all

#!/bin/sh
rm /sbin/init
cp /sbin/init-puppy /sbin/init

rm /sbin/poweroff
cp /sbin/poweroff-puppy /sbin/poweroff

rm /sbin/reboot
ln -s /sbin/poweroff /sbin/reboot
gxmessage Set for Puppy Poweroff -font 16 -center -timeout 4 

set_pseudo_systemd.sh

Code: Select all

#!/bin/sh
rm /sbin/init
cp /sbin/init-systemd /sbin/init

rm /sbin/poweroff
cp /sbin/poweroff-systemd /sbin/poweroff

rm /sbin/reboot
cp /sbin/rebooy-systemd /sbin/reboot

notice the creation of the symlink for reboot. Make duplicates of the systemd parts so with the scripts you can switch back and forth and insure a clean Fossapup64 reboot or shutdown.

[mplsvpn]

I followed the steps you specified. When I typed "apt help" in console, the response is "command not found". What did I do wrong? Thanks.

[bigpup]

Try:

Code: Select all

apt --help

[fredx181]

I followed the steps you specified. When I typed "apt help" in console, the response is "command not found". What did I do wrong? Thanks.

Try:

Code: Select all

apt --help

That shouldn't make any difference, "apt help" should give help options too, @mplsvpn , apparently something went wrong in your setup.

[fredx181]

Here is a link for the apt_sfs_load_fossa_amd64.sfs which is written by wiak.

I had a look inside this, but couldn't find the 'apt' binary, am I missing something perhaps ?
(that could explain the 'command not found' as reported by mplsvpn)

[rockedge]

@fredx181 Oops my fault!! I forgot to include that there is a special version adrv_fossapup64_9.sfs that needs to be swapped in to the frugal install directory to replace the existing one.

So both apt_sfs_load_fossa_amd64.sfs and the special version adrv_fossapup64_9.sfs must be loaded. The adrv_fossapup64_9.0.5.sfs during boot and then load the apt SFS with SFS_Load-on-the-fly.

Here it is.
adrv_fossapup64_9.0.5.sfs
apt_sfs_load_fossa_amd64.sfs

[mplsvpn]

Thank you for the responses. When I tried to install the package, scrcpy, I received the following error.

root# apt install scrcpy
Reading package lists... Done
Building dependency tree... Done
E: Unable to locate package scrcpy
Root#

I installed scrcpy in Ubuntu successfully without any error. Please advise how to install this package in Fossapup. Thanks.

[mikeslr]

There are a couple of problems with requiring the use of an adrv.sfs. The first is that an adrv.sfs will automatically be copied into RAM on bootup and can not be unloaded during a session. In order to unload it you have to physically move it where it won't be found by initrd and reboot.
Examining this particular adrv's contents suggests that using it involves radical changes to how Puppys work. So, while it may accomplish its objective, other applications under that Puppy may no longer function properly.
Under most Puppys, adrv is one of the only two READ-ONLY SFSes you can easily create. And I'm not sure that converting this adrv to an ordinary SFS which has lower priority than the base.sfs, ydrv and one's SaveFile/Folder would result in a system enabling you to employ apt-get.

Perhaps PKg-Cli alternative to using apt-get might be better. viewtopic.php?t=4802. See this thread for a full explanation and tips. https://oldforum.puppylinux.com/viewtop ... 26#p985531. But AFAIK, it can be used to add repositories and install applications together with their dependencies.

[rockedge]

@mplsvpn You need to first in a terminal:

Code: Select all

apt update

then

Code: Select all

apt install scrcpy

The problem is you do not have a package list for apt to check through to identify the package in the repos and pull the needed dependencies, so the first command goes gets and downloads the package list (like the catalog) so apt knows what to do and where to go.

[mikeslr]

@fredx181 Oops my fault!! I forgot to include that there is a special version adrv_fossapup64_9.sfs that needs to be swapped in to the frugal install directory to replace the existing one.

So both apt_sfs_load_fossa_amd64.sfs and the special version adrv_fossapup64_9.sfs must be loaded. The adrv_fossapup64_9.[color=#FF0040]0.[/color]5.sfs during boot and then load the apt SFS with SFS_Load-on-the-fly.

Here it is.
adrv_fossapup64_9.0.5.sfs
apt_sfs_load_fossa_amd64.sfs

@ rockedge, shouldn't the above adrv just be named adrv_fossapup64_9.5.sfs ? Isn't that the name fossapup64's initrd looks for?

[spiritwild]

Just a fair warning......
If you are not familiar with apt, you can fall down a rabbit hole of "wtf just happened".

I'm using devuan puppy with synaptic and if you update certain files, as with any linux flavor, you will brick the whole system.
Although, If you are like me, you have to break it 10 times before you figure it all out. It seems to be a lost art form now days

If you set up a bike ramp in the alley, you're gonna eat gravel at least once!! lol

[bigpup]

I followed the steps you specified. When I typed "apt help" in console, the response is "command not found". What did I do wrong? Thanks.

Try:

Code: Select all

apt --help

That shouldn't make any difference, "apt help" should give help options too, @mplsvpn , apparently something went wrong in your setup.

Apt options:
-v, --version ->Display information about what version of apt you are using.
-h, --help ->Display a brief listing of available commands and options.
-y ->Assume the answer "yes" to any prompts, proceeding with all operations if they are possible.
--assume-no ->Assume the answer "no" to all prompts.
-d, --download-only ->For any operation that would download packages, download them, but do nothing else.
-f, --fix-broken ->When used with install or remove, this option attempts to fix any broken dependencies.
--no-download ->Do not download any packages. This forces apt to use only packages it has already downloaded.
-s, --simulate ->Simulate operations, reporting what they would do, but make no changes to the system.

[4ndr01d-Believer777]

@fredx181 Oops my fault!! I forgot to include that there is a special version adrv_fossapup64_9.sfs that needs to be swapped in to the frugal install directory to replace the existing one.

So both apt_sfs_load_fossa_amd64.sfs and the special version adrv_fossapup64_9.sfs must be loaded. The adrv_fossapup64_9.0.5.sfs during boot and then load the apt SFS with SFS_Load-on-the-fly.

Here it is.
adrv_fossapup64_9.0.5.sfs
apt_sfs_load_fossa_amd64.sfs

Great! But when I go to install something by apt it usually gives two errors

1- W: No sandbox user "_apt" on the system, can not drop privileges E: Sub-process /usr/bin/dpkg returned an error code (1)

Or

2- dpkg: error processing package systemd (--configure):
installed systemd package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)

Among other packages. So I can't use the add repository, neither gdebi nor apt itself. But I was very grateful that I was able to install apt through sfs. By the way, Where did you get it?

[mikewalsh]

Morning, gang.

Now then, guys; put me right on this, can you?

Am I right in assuming that the original adrv needs to be removed, then replaced by this custom version? Because this then leads to re-asking what mikeslr asked above; surely, Fossapup's initrd.gz won't see 'adrv_fossapup64_9.0.5'? I haven't even looked, but I don't think I need to.....I'm certain Fossa's initrd.gz will be looking for 'adrv_fossapup64_9.5.'

Instructions don't say anything about SFS-loading/overwriting the original adrv AFTER boot....

Mike.

[rockedge]

Am I right in assuming that the original adrv needs to be removed, then replaced by this custom version?

Yes this is correct. And it should be named the same as the one it replaces.

I will boot into a long time working version to refresh on how it all goes together.

[mikewalsh]

@rockedge :-

I know I asked about this quite some time ago. Life got in the way, and it kinda got pushed onto the back burner & forgotten about.....until I re-read the thread yesterday when it came back onto the front page again.

I would like to give this a try at some point - I think I've got the spare time over the next few days, at least - but I wanted to clarify mikeslr's point about the adrv name. Having been playing about with one or two older Pups recently, re-building the initrd.gz after modifying their DISTRO_SPECS file, this stuff is fresh in my mind ATM.

Mike.