PPM is dead - long live ... something else? [discussion]

[01micko]

@dimkr has apt working in dpup and upup

@peabee has xbps in voidpup

@jamesbond3142 created woof-next an age ago. Why didn't we follow it up?

I'm interested in adding slapt-get to spup variants (slacko and friends).

Post ideas here and I'll make this a sticky. (pinned)

[peabee]

PPM is still in VoidPup (if slightly hidden) - VPM (xbps) is only for Void's xbps packages - PPM is for everything else including .PETs

[dimkr]

I think it would be super nice to have a lightweight gtkdialog "app store" that uses Flatpak. Maybe we should invest in good Flatpak integration, because that's where 99% of users can find 80% of the applications they use. "Native" package managers can take care of the remaining 20%, and PPM is useless and even risky to use.

[rizalmart]

I think it would be super nice to have a lightweight gtkdialog "app store" that uses Flatpak. Maybe we should invest in good Flatpak integration, because that's where 99% of users can find 80% of the applications they use. "Native" package managers can take care of the remaining 20%, and PPM is useless and even risky to use.

However the problem on flatpak was the flathub repo. It always throws UNACCEPTABLE TLS CERTIFICATE error message

[dimkr]

However the problem on flatpak was the flathub repo. It always throws UNACCEPTABLE TLS CERTIFICATE error message

You're using an old and possibly dangerous CA certificates bundle. Don't blame Flathub.

[rizalmart]

However the problem on flatpak was the flathub repo. It always throws UNACCEPTABLE TLS CERTIFICATE error message

You're using an old and possibly dangerous CA certificates bundle. Don't blame Flathub.

You're absolutely wrong the CA certificates bundle that I used was came from official slackware current repo. I tried other flatpak repo especially kde repo and they work. Only in flathub repo has the problem

[sc0ttj]

Take this all with a pinch of salt... And no asked me, but (surprise, surprise) I think you should just develop Pkg more:

• use the Github repo that's already there, make it the main repo
  • ditch the rizalmart fork (integrate his changes into main repo before the fork goes in crazy direction)
• fix dep resolution to be faster - replace 1 func (called get_deps IIRC), use awk instead of bash
  • this is by far the biggest bottleneck in terms of runtime speed
  • could also rewrite pkg add <PKGNAME> to do concurrent downloads & installs, right after dep resolution, while leaving the other more granular/seperate commands (download, install, etc) alone
• cut out the least used/most pointless/redundant commands/features, as needed
• update the 3 frontend UIs a bit, or whicher one(s) you wanna maintain
• add FlatPak support (or whatever - it already supports load of package formats, inc SFS, so why not)
• ..etc

Obvs Pkg can live alongside PPM, or on its own if you remove all of PPM minus 1 or 2 scripts that Pkg relies on..

Before ditching PPM entirely, you could port bits of code from it into Pkg, as needed, before PPM itself is removed. Should be not toooo hard as PPM and Pkg are compatible anyways.

Pkg can (prob) also live alongside dimkrs apt-get SFS easy enough, and Pkg already supports adding PPA repos anyway (no apt-get needed).. so PPAs added using apt-get are probably picked up fine by Pkg, etc..

Likewise for pkgtools - Pkg "knows about" its third party repo files etc, and can convert/use them.

But unlike pkgtools/slapt-get/etc, apt/apt-get, etc, Pkg works in all Pups, no matter which distro it was built from. Having the same, consistent tools and API across all pups is nice.

Pkg is divided into lots of (mostly) little functions.. It's easy enough (compared to PPM) to write replacement functions to replace/update whole commands/features..

It's therefore also relatively easy to add in new stuff, while leaving the old functions there, renamed, for legacy support (if PET standard or repofile standards change, for example)..

Pkg could be setup to use separate "security" repos, and print a list of package security updates to install at boot (like Slackware sometimes does) - but I was always fighting against PPM/0install, which IIRC, merges security and main repos before Pkg does its thing.

Pkg has a pretty simple yet powerful plugin system, that can be used as a "post install" hacks/fixup routine at build time (in woof) and run time (end users in Puppy).

Lastly, Pkg has so few dependencies, it's nearly ready to work from within the initrd (just need comm and a few more things in there), or a similarly tiny filesystem.

<insert other reasons for Pkg here>

[dimkr]

Obvs Pkg can live alongside PPM, or on its own if you remove all of PPM minus 1 or 2 scripts that Pkg relies on..
Before ditching PPM entirely, you could port bits of code from it into Pkg, as needed, before PPM itself is removed. Should be not toooo hard as PPM and Pkg are compatible anyways.

Nobody here is working towards improving PPM, and it's essentially unmaintained for years.

I think the first step towards closing this issue should be fixing #2798. I'm more than willing to remove PPM from my builds. And, if pkg is a better replacement with >= feature parity, I see no reason to keep PPM alive ("alive" as in "in the repo but in a sad, unmaintained state").

Pkg can (prob) also live alongside dimkrs apt-get SFS easy enough, and Pkg already supports adding PPA repos anyway (no apt-get needed).. so PPAs added using apt-get are probably picked up fine by Pkg, etc..

The question is why add pkg to a Puppy with apt. Ideally, I'd like to have neither PPM nor pkg: apt works nicely, it's fast, and the Debian/Ubuntu guides and tutorials one finds online work as-is. A second package manager creates confusion, inconsistency (does pkg handle Recommends packages the same way as apt?) and issues (like disagreement between the package manager, whether or not package x is installed). Therefore, if PPM is replaced with pkg or something else, I still think this second package manager should be optional.

[sc0ttj]

I agree Pkg can/could be optional - but i think Puppy should have at least one package manager available as a choice that works across both slack and deb pups (and Arch pups and whatever else woof supports) .

The question is why add pkg to a Puppy with apt

• Apt can't create PET or SFS packages
• Apt can't create Puppy packages repos
• Pkg is only a few kbs added onto the SFS
• Pkg can be used across wider range of pups to handle provisioning, install of dotfiles and packages, etc
• Pkg integrates with petbuild, slackbuild, src2pkg, etc
• Pkg can/could be used inside woof at build time for various tasks
• Pkg is a fairly useful tool in "puppy shell scripting" (it makes writing installation/setup/wizard script ways easier)
• and a bunch of other "puppy" reasons like that

Users may not care about that kinda stuff though. Obvs I just offer all that as info to mull over.. Do with it as you will.

EDIT:

Just to be clear I think it's a great option to have Apt-Get in a .deb based pup, and to have slapt-get in slack based pups, too.. but do think it would be nice to have the option of using the same tools across different pups - for user installation scripts, pkg building from source, etc.

[sc0ttj]

So maybe in an [my] ideal world:

• Pkg was be included by default in any Puppy, unless specifically disabled in Woof
• The option to include apt would be offered, if you're building a .deb based pup
• The option to include pkgtools/slapt-get would be offered, if building a Slack based pup
• The option to include of xpbs would be offered, if building a Void based pup
• and so on

[dimkr]

I agree Pkg can/could be optional - but i think Puppy should have at least one package manager available as a choice that works across both slack and deb pups (and Arch pups and whatever else woof supports) .

I like the "one application per task" idea and prefer to have one package manager in my builds: less bloat, less things to test, less things to choose between. Users can always install the second package manager, at their own risk.

(apt happens to be the fastest and most reliable package manager out of the three options, so I think it's the best candidate for the package manager slot.)

Apt doesn't help you make PET packages, cant create Puppy packages repos, and a bunch of other reasons like that.. Users may not care about that kinda stuff though.

The .pet package format and its package list format have their shortcomings (for example: missing support for "multilib" systems and inability for a package to depend on package A or package B). I think woof-CE should be decoupled from both, so they can be phased out in favor of something better.

As for easy creation of packages - it shouldn't be super hard to write a "dir2pet" that produces packages of another format, or write a tool that builds a repo from a bunch of packages. I don't think that easy creation of packages justifies the complexity and the (impossible to solve) problems introduced when you have multiple package managers.

Anyway, I don't really care if and how the problems with PPM are solved, as long as I can leave it out of my builds and choose the one package manager that stays.

[gyrog]

Maybe I'm a dinosaur.
I've been using one Puppy or another as my daily work-horse for many years now.
In that time I've not dabbled in other Linux's, so despite all it's problems, the only package installer I'm famliar with is PPM.
Puppy deserves a package installer that works consistently accross all Puppies, preferably with an easy to use GUI. I don't care if it is just a front-end to the Puppy's "native installer or "pkg", and it should support ".pet", there is just so much Puppy software in this format..

If I wanted an OS that was just like debian, I'd use debian.

[dimkr]

If I wanted an OS that was just like debian, I'd use debian.

If Debian has a good package manager and dpup needs one, too, there's no real need to reinvent the wheel, and PPM/pkg/whatever will always be slow (because they're shell scripts and do everything sequentially) and unreliable (because they don't mimic apt well enough).

I see some value in the idea of one package manager for all Puppy family distros, but if it's a bad one, I don't see the point.

I am willing to have PPM and pkg in my builds only if they're thin wrappers around apt-get install.

[techrockedge]

don't like apt-get. Getting closer and closer to Debian then why call it a Puppy at all? Pkg with some work could be equal to apt-get across Puppy Linux distro's.

[dimkr]

don't like apt-get

Why? Because of a technical limitation or a design decision you disagree with, or because it's not an in-house Puppy application?

[techrockedge]

I can work with apt-get. I have a Fossapup64 set up with wiak's SFS plugin for over a year now that works very well considering it is experimental. I install and do total system upgrades with it. I use PPM very rarely and for very specific packages (mostly PHP modules) I still need to do some manual checks that some systemd changes to Puppy's /sbin/init, /sbin/poweroff and /sbin/reboot have occured during the upgrade. I have super simple scripts that change those back to the Puppy versions.
Mostly it is technical reasons. Though apt-get is 1000 times better than PPM in all respects. And now I'm biased towards Void's XBPS and runit. I also wonder what splinter effect will occur to Puppy Linux when each flavor has a different package manager.
Which GUI wrapper for APT will the standard in the Vanilla versions?

[peabee]

There is a good discussion of this topic on the forum:
https://forum.puppylinux.com/viewtopic.php?p=63754#p63754

[mavrothal]

I think that PPM or pkg, whatever is decided to be present, should get a little top function that will test for the presence of an upstream package manager and its associated files and redirect all packages, but the pets, to it.
In the presence of this upstream package manager pets should be handle by a new little application (say “pet installer”) that will do ONLY that. Install user chosen pets and remove user-installed pets. Should have its own database for user installed pets and any developer-defined external pet database. Should not mess with the puppy build files and the upstream package manager packages.

If a puppy builder wants to avoid the compat-distro package manager and go with PPM-pkg only, should also take care of any issues that may arise.

Regarding the forum discussion, I find very interesting that long time "skeptics" of traditional puppy want it to stay the same!

[dimkr]

I think that PPM or pkg, whatever is decided to be present, should get a little top function that will test for the presence of an upstream package manager

I propose #3325 as a super minimal solution that satisfies my needs and doesn't change anything for anyone else. It makes PPM a .pet-only package manager if bdrv is loaded.

Synaptic, gdebi, etc' are already configured as the default when bdrv is loaded, so a user who wants to use PPM exclusively can unload PPM to make it the default handler for .deb packages as well.

If this PR is merged, that's a solution I can live with, and I don't care much if PPM stays the abandonware that it is. And I don't mind keeping PPM in my builds, if its "attack surface" is reduced so much.

Regarding the forum discussion, I find very interesting that long time "skeptics" of traditional puppy want it to stay the same!

They criticize Puppy and describe it as inferior when they do things differently, offer their "help" in the form of long forum posts and zero pull requests, blame Puppy developers for stealing their code and ideas when they do something they consider to be similar, and praise the parts of Puppy nobody likes (like PPM) for dubious reasons.

If I read between the lines correctly, their relationship with Puppy isn't ambivalent: they take advantage of the Puppy "brand" to attract more users and participate in conversations of this sort to differentiate their work from Puppy. They need Puppy to exist and be as bad as possible so they can keep doing their thing.

[dimkr]

What happened to #2186?

[gyrog]

I've been a Puppy user since before the release of "Dingo", and I'm familiar with PPM but not any others.
I also have a few different Puppies installed on my commputer at any time.
Learning a new package installer for each different Puppy is not on my bucket list.

But I have no problem with accepting that the current PPM has no future.

I would like to see a GUI pakage installer for Puppy that works on all Puppies.
It should use the native CLI installer to do most, if not all, the work,
only doing actual work for Puppy exclusive archive formats, e.g. .pet
and even then it could simply convert it to a standard format and then call the native installer.

Unfortunately I don't see myself as an appropriate person to develop this,
since I have no familarity with (or inclination to acquire same) the various upstream package installers.