Puppy Linux Discussion Forum

[jpeps]

[Amgine]

Cat In The Bag by Tygart, on Flickr

My Cat not really a dog person, accept for Puppy.

[harii4]

@sickgut

You might be interested in what Big_Bass is working on :

[Lobster]

[saintless]

[nooby]

[sickgut]

[tlchost]

[sickgut]

After messaging John Murga the guy who runs this forum (as if we didnt already know that) Pussy will stay on this forum. I just presumed because i was separating from Puppy and Pussy is no longer going to try to be a Puppy that Pussy had no place on a Puppy forum, but im told its ok.

so im leaving the puppy world to do pussy things but not going very far

[mavrothal]

Well I do not know if this is the way of the puppy or not, but looks like a waste to keep compiling the same apps or being forced to change puppy to use one app because is only available for this puppy version.
I guess one of the reasons of the wider appeal of puppy5.2.x is its compatibility with ubuntu repos. Something that puppy5.3.x repeats with slackware repos. Pussy's appeal is not coincidental either. So package availability and consistence should not be overlooked.

PPM was built the way it is, back then because served certain needs for ONE or few highly similar puppies and puplets. But today there are 5 main stream puppies and countless pupplets, most of them not compatible with eachother. So I think PPM and pets should change a bit to fit the new reality.
I think that Puppy can have its own equally wide(?) repo if some kind of package auditing and tool-chane consistency is implemented. The puppy package management could easily be improved with minor investment (and a lot of knowledge...).

What it really needs is to add 2 new files in the pets, and PPM to check them and act accordingly.
One file should contain something like the ldd output for the included binaries eg `ldd --verbose binaries_in_pet >> petname.ldd' and the other the standard `petneme.files', that PPM generates (only after installation...).
The first file would be equivalent of "dependencies" while the second of "provides".

There are some more "dependencies" that may be more difficult to automate. The programs that scripts in the pet call upon and are not included in the pet (or listed as dependencies).
I guess that someone could search for the "exec" or "which" command in the scripts but I'm sure that a lot would be missed. Maybe someone has better ideas on how to "automate" this and append it in the dependencies file.

Anyway, having these 2 new files in the pet outside the tarbal, PPM could check before installation (the way it checks for size) and decide if additional files are needed, where to find them (assuming that a "provides" database is generated for every puppy-repo) and if preexisting files will be overwritten or updated.

If these 2 new files are not present or are empty, PPM could issue some scary warning, like "installing this package will brake your system".
This hopefully will deter installation of miss-formed packages and encourage compliance by pet developers.

As for consistency, I think that "agreeing" in every cycle on kernel, gcc and xorg versions should be sufficient and if not, PPM should at least be aware of this and act accordingly.

I'm sure that people can think and do better than that, but the general idea is that with well formed and audited packages Puppy would have nothing to envy from other distros. Most of the packages are already somewhere in this forum or some repo sites in and out of ibiblio. There are just hard to find and questionable to use.
This should improve somehow.


I do not know what sickgut will decide to do with pussy or puppy, but I would rather see him stay, and maybe work along these lines too.

Just my 2 c.

PS: Ooops sickgut decided already

[stu90]

I agree with many of Sickgut's points - my secondary OS is Bodhi linux they have their own .bod packages that contain all dependencies for popular applications yet still retain apt-get / synaptic package manager to ubuntu repos.

If Puppy was built from say debain or slackware why couldn't we do the same - keeping a repo of .pets as optimized packages yet with the full compatibility of an established and well maintained repo to fallback on if x,y,x, package is not maintained in the puppy repo.

[big_bass]

saintless

[saintless]

[RSH]

[jpeps]