The Power of Pkg-CLI and Upgrading to PHP7.4 in Bionic64

[rockedge]

@sc0ttman's Pkg-cli never stops amazing me. To take a break periodically from building KLV's I decided to address the Puppy Linux Wikka we have slowly sailing along like a ghost ship. Turns out the dev's of the software we use, Wikkawiki have called it quits after 15 years of development and support for it. So I am looking at replacement software to again bring us to a more modern system that again will be added to with the wealth of information around both forums and that the community can contribute to.

This set up is running a test cutting edge ZoneMinder v 1.37.6 (master branch) successfully and now MediaWiki which requires a minimum of PHP7.3+ which poses the problem that Bionic64's Ubuntu repos only provide up to PHP7.2+.

But using pkg I was able to add the Ubuntu PPA for PHP7.4+ and all the php modules and extensions (extensive) that both of these major packages need to run. Then with a search done with the PPM to give me the exact package names, I used pkg add to install all the extensions for PHP7.4 and even the tricky ones that need dependencies from earlier PHP versions, installed with ease. Pkg output gave me the necessary missing and or needed dependency messages to make it possible to track down some of those lib's that need to be tricked into installing. Pkg-CLI really performed well in this case of sometimes not straight forward installations.

Screenshot(22).png (157.41 KiB) Viewed 2033 times

My testing platform is on a Dell Optiplex 990 running Bionic64-CE (woof-CE built) with:

• Web Server = Hiawatha v 10.10

• PHP Version = v 7.4.27

• Database = 10.1.44-MariaDB-0ubuntu0.18.04.1 - Ubuntu 18.04

• phpMyAdmin = v 5.0.4

Screenshot(23).png (108.8 KiB) Viewed 2033 times

So it is possible to have several versions of PHP7+ onboard and easily selected by modifying the hiawatha.conf file and restarting hiawatha. Which is handy when testing different PHP based software packages.
Pkg-CLI proved to be versatile and together using the PPM as a package name search tool, proved again the power of Puppy Linux as a development platform and it's excellent qualities for running solid, stable fully featured Web Servers.

Screenshot(25).png (24.5 KiB) Viewed 2027 times

Screenshot(26).png (54.01 KiB) Viewed 2019 times

[takenp]

I also prefer to use it in Bionic Pup. BTW - how did you manage to add 'the Ubuntu PPA for PHP7.4' ?

thx in advance

[rockedge]

@takenp

I add the Ubuntu PPA from here -> https://launchpad.net/~ondrej/+archive/ubuntu/php like this :

Code: Select all

pkg add-repo ppa:ondrej/php
pkg repo-update

Now select and use the PPA repo:

Code: Select all

pkg repo bionic-ondrej
pkg add php7.4 php7.4-cgi

Then add some extensions:

Code: Select all

pkg add php7.4-curl php7.4-memcache php7.4-mysql php7.4-bz2_7.4 php7.4-zip php7.4-zstd php7.4-intl_7.4.27-1 php7.4-xm

Open the Puppy Package Manager update the repos after enabling the repo bionic-ondrej then can be used to search for the names of the available PHP7.4+ packages.

[sc0ttman]

Open the Puppy Package Manager update the repos after enabling the repo bionic-ondrej then can be used to search for the names of the available PHP7.4+ packages.

Out of interest, why did you use the Puppy Package Manager to do an update at this point?

[rockedge]

Out of interest, why did you use the Puppy Package Manager to do an update at this point?

Mostly done to specifically ensure that Pkg and PPM are on the same update level.

I use the PPM to search for the correct package names to then feed those to Pkg to install. I did this because I wasn't good at searching the repos for PHP modules using Pkg alone yet and found PPM was easy to use as the repo browser.

I have not worked with any of the Pkg GUI's extensively enough yet to determine how those work to do the same. Guess I should though at this point.

[wiak]

Was pointed out to me:

Plenty nastiness going on elsewhere: https://github.com/puppylinux-woof-CE/w ... nt-3388758

Nevertheless there are valid reasons why Puppy users want to still have PPM available, and that is the main reason I feel it should remain (whilst acknowledging the problem a mix of package managers can cause). Anyway, I have a thick skin - sticks and stones and so on; ridiculous really and a bad and insular attitude at woof-CE clear to see.

I guess I should never have contributed that dpkg/apt sfs addon for Fossapup a year or so back: viewtopic.php?p=16601#p16601
but it was a not-planned side product of a small (79MB) WDLGO focalfossa I had made and I thus had that separate dpkg/apt sfs addon available and thought some others might find it useful. Forum member s243a, for example, was trying at the time to get dpkg/apt working in Puppy, via some woof-next code I believe, but wasn't quite getting there, but: viewtopic.php?p=16313#p16313

It was never my intention to kill PPM/pkg (and doubt that was jamesbond's intention with his earlier, and working as far as I know, woof-next either), though I do know they have limitations - but being able to install from multiple distro repos is really quite a useful achievement - despite official repo package managers generally being best for their own upstream distro's repos.

[dimkr]

Nevertheless there are valid reasons why Puppy users want to still have PPM available

What are they?

The main reason I see in the various pro-PPM posts is compatibility with .pet packages, but 1) pkg can do that too and 2) PPM can be replaced with something smaller in scope and less bug-prone, which handles .pet packages only. Why keep PPM then?

[rockedge]

@dimkr
I do not care about PPM per say. But I DO care about a decent GUI for Pkg and the continued PET support one way or another. You do understand that I am using PPM like a package browser and a way to look at an uninstall package(s) lists, then Pkg to install????

I think Pkg should remain more than a stripped down PET installer.

And what does your post have to do with the PHP 7.4 upgrade in Bionic?

I read https://github.com/puppylinux-woof-CE/w ... nt-3388758
did your feelings get hurt or something?

[dimkr]

And what does your post have to do with the PHP 7.4 upgrade in Bionic?

Dunno, I replied to @wiak's reply.

did your feelings get hurt or something?

Nope, I have no feelings for PPM. I want PPM to go away: it breaks Puppy installations, confuses users who need to choose between "Puppy Package Manager" and something else, and convinces people that Puppy is incompatible with packages that work just fine if you install them using a working package manager.

I just find this opposition to the idea of dropping PPM, or at least replacing its internals with pkg (while keeping the same UI, or building a better one), surprising, especially when it comes from people who criticize Puppy from time to time, or people who promote other package managers. In the past, many Puppy users complained about PPM and came up with proposals to replace it or return to a "last known good version", but now it looks like everyone is perfectly happy with its half-broken state (calling it "quirky", "unique" or "traditional"): everyone wants it to stay, but nobody volunteers to fix it and some even deny the need to do so.

[mikeslr]

Nevertheless there are valid reasons why Puppy users want to still have PPM available

What are they?

The main reason I see in the various pro-PPM posts is compatibility with .pet packages, but 1) pkg can do that too and 2) PPM can be replaced with something smaller in scope and less bug-prone, which handles .pet packages only. Why keep PPM then?

PCs are manufactured to run Windows. A Linux Operating system is an after-market product. Who is your market? Who are your competitors for that market? What advantage does your product have which your competitors can't or won't provide?

Why choose a Puppy rather than one of its binary-compatible Distros; or one of the dozens of other Linux operating systems?

Until you have a market objective you can't make rational design choices. Pyrrenese and dachshunds are both great dogs. But you can't give the former away to chase down badgers, nor the latter to guard sheep.

Almost all newbies are Windows Immigrants: accustomed to having had their hands held when additional applications are installed. Few are from Major Linux Distros; and fewer still Linux experts. One of Puppy's objectives is to be 'User-Friendly'; another to work on old-resource-poor computers.
Although newbies may not be familiar with PPM, its learning curve is vastly shorter than apt or apt's equivalents on other Distros. So when you talk about replacing PPM, the replacement would have to be synaptic (or its equivalents on other distros).

Really user-friendly package management has progressed beyond synaptic to systems like Linux Mint Software Center, https://www.fossmint.com/wp-content/upl ... Center.png which not only installs applications and all their respective dependencies but prior to installation provides a User with recommendations, reviews and alternatives.

Puppys are not a distro but rather a family of distros; each Puppy being woofed using the binaries of some distro, most often debian, ubuntu and slackware. To a large extent, applications for the last are incompatible with the former and vice-versa. [Well, at a minimum lacking dependencies].

Major distros are designed as a unity, constantly reading from and writing to storage. Puppys are designed to operate in RAM. With the exception of the optional SaveFile/Folder, Puppys' operating system is cached in RAM on boot-up. Even with the compression used when creating that cache some amount of RAM will no longer be available to do actual work. The amount of RAM remaining is important if it is remembered that Puppys may be run from 'old-resource-limited' computers. To achieve that, a Puppys replaces much of its binary-compatible's infrastructure with 'home-grown' light-weight scripts: Heavy-weight foundation applications such as Qt5 are not included.

On its own, PPM limited to its own unique repositories --and especially with Quickpet, when available and Fan-built-packages available for download from the Additional Software Forum-- is fine because the packages so obtained include required dependencies.

The real problem with PPM is that it relies on its binary-compatible-distro's assessment of what libraries are dependencies. Apt (or equivalent) alone could do no better and would require a steeper learning curve. My experience using synaptic under Puppys is that it too, occasionally, will miss dependencies.

One of the ways Puppys achieve their small foot-print in RAM is the employment of SFSes under aufs. An SFS under aufs can be loaded and unloaded at will. An unloaded SFS requires NO RAM. [An unloaded SFS also does not conflict with a different application employing other libraries: note the conflicts between KDEnlive and Openshot whose IIRC python modules were incompatible]. [As far as I know overlay does not provide the same flexibility as aufs.]

PPM facilitates the creation of SFSes. It can be configured to download but not install an application and all its dependencies; and the user can specify a unique location for that download. Apt, synaptic, and such like Linux Mint Software Center AFAICT download AND Store applications and libraries ONLY in /var. The User has to choose not to keep files being installed or remember to clear /var after each install otherwise (a) its contents will waste space (and perhaps RAM, see below) and (b) present the user with the problem of figuring out which are the required files for the new application and which are there from applications previously installed.

[How does Remastering handle /var? I assume remastering doesn't include its contents. An the same would be the case using amethyst's nicOS-Utility-Suite's Save2SFS which will capture a adrv.sfs, ydrv.sfs, savefile/folder and the content of RAM to create a new adrv.sfs or ydrv.sfs. And while it may not use much RAM to do so, some RAM will still be employed on boot-up to 'index' the unneeded contents of /var in a SaveFile/Folder or overlay].

That addition of synaptic (not apt alone) to Puppys would be a step forward for most newbies as it is likely they have computers with sufficient Storage Space and RAM to eliminate the need for application SFSes: have all new applications installed into SaveFile/Folders or overlays. But for most of the 'Third-World' and many others who can not afford Resource-Rich computers PPM should continue to be a Puppy feature, albeit with some modifications.

The problem PPM poses when another package manager also exists is that the 'left-hand doesn't know what the right-hand is doing'. Apt/synaptic is unaware of the libraries PPM installs, and vice-versa. I've avoided that problem under VoidPup and VanillaDpup by employing PaDS, https://www.forum.puppylinux.com/viewtopic.php?t=933 to create SFSes and the Save2SFS module, https://www.forum.puppylinux.com/viewto ... 983#p12983 to create adrv.sfses &/or ydrv.sfses. Both techniques avoid writing files to the SaveFile/Folder. Apt/Synaptic doesn't have to know about their contents. Similarly, Apt/Synaptic doesn't have to know about the contents of an AppImage created using fredx181's Create-portable-AppImage, https://www.forum.puppylinux.com/viewto ... 3250#p3250. An AppImage provides this advantage: it is mounted as an entire file-system rather than, as with SFSes, its contents being distributed to folders in RAM, potentially overwriting and conflicting with the files required by other applications.

Currently PPM offers three significant options: (1) Autoinstall, (3) Download Packages -- no install, and (4) Download All -- packages and dependencies. I suggest adding two other: (5) Create SFS from packages and dependencies, and (6) Create AppImage from packages and dependencies.

Selection of the latter 2 should leave the 'build folder' to be manually deleted by the User, or 'fleshed-out' with additional libraries should that prove necessary.

Recognizing that coding is not my forte, I would guess that such additions would not require an entire re-write of PPM; and that much of the necessary coding already exists via PaDS and Create-portable-AppImage.

@ sc0ttman and mistfire: IIRC, pkg-cli has the abilities to (a) just download specific libs and (b) on its own create SFSes. I haven't been able to figure out how. Perhaps you could be so kind as to post examples to the pkg-cli thread.

[backi]

@mikeslr wrote (among other):

5) I suggest adding two other: (5) Create SFS from packages and dependencies, and (6) Create AppImage from packages and dependencies.

Just want to mention here (in case there is no wider awareness about those mostly unrecognized cool/nifty little Tools/Apps/Guis for creating sfs (squashfs) Modules and portable-AppImages automatically ,that can be found in @fredx181 Ubuntu and Debian Dogs.

One is called "AptToSfs" the other is "Sfs-Portable" (for creating portable Sfs (Squashfs) Modules/Programs/Apps.

"AptToSfs" works with Synaptic/Apt but instead of installing the chosen Programs (or Debs) it automatically creates portable/loadable Sfs/Squashfs Modules from them instead,
I really love it .......Veeeery cool.

I prefer using AppImages or portable (sfs/sqashfs) Modules myself instead of Installing them........seems more secure and flexible to me.

Since i am not a Developer myself......maybe this Hint is useful for somebody more privy to this Kind of programming Stuff.
Maybe @fredx181 himself could comment more on this Kind of Topic.

Keep on rocking

[williams2]

Cache and buffers are useful and are created and managed (by the kernel) completely automatically.
Most users do not need to think about it, at all
The memory in the cache space is instantly available to applications that need it.

he real problem with PPM is that it depends on its binary-compatible-distro's assessment of what libraries are dependencies

The thing about any package management system (PPM, aptget ...)
is that it is mostly about the packages.
If you can select a package, any package, and it just installs and runs OOTB,
then the package manager will be considered to be working well.

80%. 90%, 99.99% of what a package manager system is all about, is the packages.
If you want a good package management system,
most of the work would be creating and maintaining packages.

And each distro and each version of Puppy would need it's own packages that all work OOTB.
Which is a lot of work.

The thing about a package management system, it's really mostly not about the user interface,
It's mostly about the packages.

How does Remastering handle /var

My script copies all of /var to my temporary dir,
then it deletes a lot of files and dirs that are in the temporary /var.
But not all of /var.

Most of the time, my save space (tmpfs in ram) is using about 5 MB. (mostly 3.5MB in pup_rw/lib/modules/)
At this moment, my save space (tmpfs in ram) is using about 236MB, but that is Firefox which is running completely in ram. If I stop Firefox, my save space (in ram) goes back to about 5MB again.

My adrv.sfs which I use instead of a save file, is about 128MB.

Summary: Its (mostly) about the packages.
And don't worry about caches and buffers. it's all managed by the kernel automatically.

[mikeslr]

@mikeslr wrote (among other):

5) I suggest adding two other: (5) Create SFS from packages and dependencies, and (6) Create AppImage from packages and dependencies.

Just want to mention here (in case there is no wider awareness about those mostly unrecognized cool/nifty little Tools/Apps/Guis for creating sfs (squashfs) Modules and portable-AppImages automatically ,that can be found in @fredx181 Ubuntu and Debian Dogs.

One is called "AptToSfs" the other is "Sfs-Portable" (for creating portable Sfs (Squashfs) Modules/Programs/Apps.

"AptToSfs" works with Synaptic/Apt but instead of installing the chosen Programs (or Debs) it automatically creates portable/loadable Sfs/Squashfs Modules from them instead,
I really love it .......Veeeery cool.

I prefer using AppImages or portable (sfs/sqashfs) Modules myself instead of Installing them........seems more secure and flexible to me.

Since i am not a Developer myself......maybe this Hint is useful for somebody more privy to this Kind of programming Stuff.
Maybe @fredx181 himself could comment more on this Kind of Topic.

Keep on rocking

Very cool, indeed, backi. Thanks for mentioning them.
Suggestive that with a little ingenuity Synaptic under Puppys might serve as the back-end for creating SFSes (maybe also AppImages) removing any need for PPM. Certainly providing a more efficient system than adding the ability to use Flatpaks and/or snapd.
[Although it may be concealed thru the use of one GUI, Operating systems offering Synaptic plus Flatpaks and/or Snaps are accessing different repositories and employing different technologies to do so].

[wiak]

To be clear. I am not myself advocating Puppy keeps its PPM or not. My stated 'opinion' (and not a strong opinion one way or the other) is that it seems to me that if Debian/Ubuntu-based Pups only provide apt/dpkg then I fail to see their 'point of difference' from the DebianDogs, which being fully Debian/Ubuntu compatible systems (pretty much I think) use apt/dpkg perfectly whilst being Puppy-sized with all the Puppy-like bells and whistles. User backi knows what I am talking about. But Puppy is a different system with its own charms and advantages - main one being (it seems to me) that you can boot up any Pup and same package manager 'works' no matter what the upstream distro repo it is based on, and it has always been a system where users can do what they like in terms of installing alien packages and so on (and yes, breaking the system if they so want...) - I see that as a refreshing characteristic, rather than focusing on the negatives of that approach.

As for PPM/pkg; fact is I have a problem in discussing these because I'm not familiar with how pkg works. I was relatively familiar with PPM itself but never studied pkg once it came along because, though interested in it, was too busy myself doing other things. I got the impression that pkg in fact relied to some extent on the underlying existence of PPM, but I may well be wrong about that? Hence I always tend to say PPM/pkg in case separating out pkg doesn't make sense, but maybe it is standalone and doesn't use PPM at all??? Otherwise I don't see why anyone would want both PPM and pkg if the latter does more (i.e. keep/develop pkg as an always available (but an option to use) in Puppy and throw out PPM if pkg not dependant on underlying PPM. However I note rockedge saying pkg doesn't have a GUI whereas PPM does in which case creating a GUI for pkg would seem the appropriate dev approach to that issue (but until anyone does that keep PPM too)?

[rockedge]

However I note rockedge saying pkg doesn't have a GUI

There is in fact 1 GUI and a terminal editor version ->

Screenshot(1).jpg (19.75 KiB) Viewed 1567 times

Screenshot(2).jpg (28.43 KiB) Viewed 1567 times

I just have not used them much yet.

[wiak]

One thing I don't understand in the 'arguments' to drop PPM is: what harm does PPM or pkg do if a user chooses to just use the Pup supplied dpkg/apt system (in Debian/Ubuntu-based Pups that is)? Alternatively, a user may choose to just use pkg... Just because it is provided shouldn't mean one or other has to be used in preference to the other - it becomes a matter of choice (but, yes, with underlying risks should some users 'choose' to mix both methods for some reason/advantage or another, and some risk-avoidance code/strategy can always be developed to improve compatibility of course). Frankly I see nothing against, for example, including something like pkg in KLV-airedale too (in addition to its usual xbps package manager from Void Linux) if it could be made to work; it isn't 'required' per se since Void xbps package manager is pretty good, but there could be times that someone might find an alternative dotpet/alien packages installer such as pkg useful surely? So what is the reason to deny options to users just because a developer doesn't like the alternatives themself? We are not all the same here; we do not all have the same mindsets, or the same wishes and desires - Puppy has always had that tendency to try to cater for all forum members as best it can - that probably is its most attractive 'point of difference' so why take that away (and especially if setting that take-away-situation up in concrete in woof-CE itself, which is the core builder of all subsequent Pups of course)?

And wouldn't it be nice for a new Puppy Jammypup64 to come into existence now that Fossapup64 is growing long in the tooth? I really hope 666philb hasn't resisted creating a Jammypup64 just because Vupup came along; Vupup is a nice distro I feel, but even dimkr says it is not a traditional Pup and personally I am fed up installing Fossapup64, which really is last generation Ubuntu now (aside from the fact it does not boot on my newer nvme-SSD HP laptop anyway...).

[wiak]

It is not as if quite a lot of hard work/recent-development hasn't been put into Pkg. Forum member mistfire, who is clearly a very competent developer is well-known to have worked on it in what he calls 'Pkg2'. Is that work being incorporated into woof-CE? and if not why not?

viewtopic.php?p=51728#p51728

From @mistfire post March 2022:

@dimkr @@peebee @@rockedge

pkg github repo is now online and open for pull request
https://github.com/rizalmart/Pkg2

[dimkr]

Is that work being incorporated into woof-CE? and if not why not?

It's easy to integrate pkg into woof-CE, but so far no one has submitted a PR that makes woof-CE use this fork.

(I think the fork should be merged into https://github.com/puppylinux-woof-CE/pkg before woof-CE starts adding this pkg fork to builds, so other people can open issues or contribute.)

[fredx181]

and personally I am fed up installing Fossapup64, which really is last generation Ubuntu now (aside from the fact it does not boot on my newer nvme-SSD HP laptop anyway...).

May not have to do with nvme-SSD in your case, fossapup64 boots fine for me on my new laptop (with nvme-SSD).

[wiak]

and personally I am fed up installing Fossapup64, which really is last generation Ubuntu now (aside from the fact it does not boot on my newer nvme-SSD HP laptop anyway...).

May not have to do with nvme-SSD in your case, fossapup64 boots fine for me on my new laptop (with nvme-SSD).

That's interesting. I couldn't think of anything else major that might prevent it booting. It does boot on an HP Elitebook laptop I have that isn't too old, but I'm pretty sure that one doesn't use nvme SSD.

Doesn't matter anyway - FocalFossa is replaced by Jammy nowadays and Vupup does boot okay on my machine but pupwise I always liked fossapup64 so hope 666philb produces something similar for Jammy.

Actually main distro I've been using on my nvme HP is Zorin, which is based on focalfossa so clearly something not in fossapup64 that my particular machine does need.

One thing Zorin doesn't work for in our usage is hplip printing to HP Desktop 2540 injet - printing works fine if I boot EndeavourOS (and worked fine with WDL_Arch64 for the couple of years I relied on that). That's more painful to me than fossapup not booting - so I'm currently planning to move our business linux machines to something other than Zorin (since only get new releases of that every two years, but I don't want full-on rolling release for the business). I become interested in Fedora (not rawhide since its bleeding edge on the whole), or maybe just based on Ubuntu, which is pretty good without being rolling releases. I don't want Debian, Arch-based distros don't provide shim for secure boot... sigh..., Centos Stream is useless to my eyes, Rocky to far from rolling - its either stable most recent Fedora or Ubuntu-based going to be... so maybe a cut down xubuntu

[wiak]

Frankly I see nothing against, for example, including something like pkg in KLV-airedale too ... there could be times that someone might find an alternative dotpet/alien packages installer such as pkg useful surely?

I really wish I could receive a clear answer on this, because honestly, if pkg could be a standalone general purpose package manager that worked across multiple-repo types, it would be so useful to me. I designed WDL initrd to boot most any root filesystem, which is how weedogit.sh is now able to boot around 35 different distros (and then all can also use exactly the same utilities others have developed for KLV-Airedale flexible functionality). Wow, a general purpose standalone package manager that could be 'bolted on', along with WDL intird, and busybox to get things started, would just be a delight to me!

But I have a feeling pkg was designed on the back of PPM which relies on all sort of distrospec-type Puppy linux stuff, or is that latter config material minimal, extractable, usable in standalone pkg manager form? If it is I would adopt and produce a little WDL initrd/busybox/pkg-based frugal install distro (as an alternative to the original firstrib_rootfs design concept which centred around using static Void linux standalone package manager (but thus limited in that shape and form to use Void repos).

I'm a computer 'hobbyist' guys. I'm not ashamed to admit it. I have little personal interest (none really) to produce the polished distro we all love using. But I like to play with something that can powerfully build up to anything - that is what all WeeDog stuff is actually about - not a distro per se in any shape or form whatsoever - not competing with any distro ever - just a mechanism for building what I like to build or help build. Not like woof-CE build system which attempt to build an end-product Pup, though capable of some similar result through the plugin build work of someone like rockedge (with the likes of KLV-Airedale as an example). So, really, it is the components like initrd, and package managers and so on, that I am myself interested in - like I've said before: LEGO. Maybe I never had LEGO as a kid.

[mistfire]

@wiak
Actually I see that PPM was a just like an app store. However I realized that its implemented backends were performed poorly. (However the package installation and removal component worked nicely) So I having an idea, that what if retain the PPM GUI for package query and selection but pkg will do the backend package management?

[wiak]

@wiak
Actually I see that PPM was a just like an app store. However I realized that its implemented backends were performed poorly. (However the package installation and removal component worked nicely) So I having an idea, that what if retain the PPM GUI for package query and selection but pkg will do the backend package management?

Sounds good, but can it do all this independently of Puppy Linux so it could be used as a standalone package manager?

[rockedge]

@wiak Can Pkg be standalone? YES

It only uses one function from the PPM when updating the repos to make Pkg and PPM use the same repo data. Change this bit of code or enhance that and I could and will add it to KLV-Airedale. As a matter of fact I will start right now on Beta17 to see how Pkg integrates. It would solve the "how do I install a PET easily in KLV?" question.

Right now I convert .pet to .deb and use xdeb to install it on KLV

One way or another...... like I compiled XBPS in Fossapup64 and began to integrate it to work on Puppy's somehow for some reasons, I will jam Pkg into KLV and see what happens.

[rockedge]

@wiak

I did it.

I successfully installed Pkg-cli into KLV-Airedale-beta17 running in a QEMU VM, then used Puppy's Pkg-cli to update the Puppy repos and then installed a PET into KLV-Airedale directly by using the Pkg-cli GUI supplied in Puppy Linux.

Screenshot(3).jpg (69.54 KiB) Viewed 1581 times

Screenshot(4).jpg (69.4 KiB) Viewed 1581 times

Screenshot(5).jpg (69.5 KiB) Viewed 1581 times

Screenshot(7).jpg (67.37 KiB) Viewed 1581 times

And here is the urxvtControl PET running (rxvt-unicode was installed with xbps-install GUI OctoXBPS).

Screenshot(9).jpg (57.78 KiB) Viewed 1569 times

[wiak]

@wiak

I did it.

I successfully installed Pkg-cli into KLV-Airedale-beta17 running in a QEMU VM, then used Puppy's Pkg-cli to update the Puppy repos and then installed a PET into KLV-Airedale directly by using the Pkg-cli GUI supplied in Puppy Linux.

That's odd... I answered above earlier today (original post hasn't appeared)! I hope I didn't Edit your own post as admin by mistake rockedge (instead of quoting part of it)...?

Anyway, as I said, that is great you managed that, and so quickly. This could be very useful indeed.

[rockedge]

@wiak My fault, I made this post first then thought I should put a post with the KLV stuff and I just copied it.....

Pkg-cli can install PET from the noarch Puppy repo so far with no errors. But it's not 100% yet on the other focal fossa Ubuntu repos and need some more adjustments.

Though the proof-of-concept seems to indicate that it will work. Now to add some mechanism that xbps is aware of PET package installs at some point once Pkg-cli works 90%+ in KLV.

The Philippines is really interesting! Crazy government. When I was a young man the USA had a huge naval base and Air Force base there.

[Clarity]

Yes, we have good people helping together from across the world.

[mikeslr]

See my post here, https://www.forum.puppylinux.com/viewto ... 937#p64937