(old)Puppy Linux Discussion Forum

I'm fairly curious about why the old dotpup package format was replaced with dotpet. From what I could remember, while dotpup used zip for a container (I think, correct me if I'm wrong) it had a number of nice additions, such as md5 inside the package itself, and one could include a nice installer script.

While some could see that as being like some form of installer rather than a package, I liked the idea of what I viewed as a "smart" package. And with some talk by members of the community about wanting a different packaging format, I kinda wonder if there are aspects of dotpup that may have been nice that could be incorporated, perhaps in some form of puplet package manager.

If Puppy had dotpup, then dotpet, perhaps maybe someone will make a package format called dotdog .

Pets have the md5 and install scripts-
http://puppylinux.org/wikka/pets

Looks like Pet packages have better dependency handling than Pup packages,
see 2.14 release notes http://www.puppylinux.com/download/release-2.14.htm

woof woof

Why thank you darkcity. That cleared it up pretty swell.
Though I will admit, I wonder how one could make a dotpet containing subpackages for different archs, since people are getting puppy on ARM and the like.

Since I noticed much of the packages that one would use, tend to be on this here forum, I wonder what would be best to deal with that? Have people post pets for each puppy, or some form of quasipackage that would contain info on where to get (via wget) packages, depending on the puppy version, and system arch.

could be either plaintext, or some form of XML to handle markup for this quasipet. For purposes of clarity, I'll refer to this as dotdog in the code below:
then again, this may be good for another topic if people think it could be useful.

One package with multiple arches is a bad idea -period, full-stop. Any package worth creating is also worth creating in all its' glory for each arch you intend to support.

\you break it out into common and arch-dependent

mybinary (a metapackage for)
mybinary-common
gtk2-common
mybinary-$ARCH

mybinary-$ARCH would have dependencies like:
libgtk2-$ARCH

amigo wrote:One package with multiple arches is a bad idea -period, full-stop. Any package worth creating is also worth creating in all its' glory for each arch you intend to support.

I kinda hear you on that one. But what I'm talking about isn't a package for multiarch, but a file that would be used in a package manager to automatically download and install the package for it's arch, and puppy.

technosaurus wrote:You break it out into common and arch-dependent

mybinary (a metapackage for)
mybinary-common
gtk2-common
mybinary-$ARCH

mybinary-$ARCH would have dependencies like:
libgtk2-$ARCH

Makes pretty good sense. But I do wonder about a metapackage involving different puppies. People seem to use Wary, Racy, Slacko, Lucid (I think), 412, Retro, etc. It's possible that one might need a separate package for these. But then again, if you list dependencies you could obtain them via PPM, but many libraries are posted here, or hosted on someones FTP or HTTP server.

And perhaps there may be software that may be less stable and usable on different kernels. Then again, for that one could use $KERN

again, this is all just my two cents.

Can the main repository handle links? That that way if something changes your can just change the link.

Im still not sure why having a mutli arch package handler would be beneficial? Wouldnt it lead to people going to the repository, selecting a package, then if its not available for there arch it would have to say "sorry not available".

The main problem, as I see it, is that maintaining a repository and testing on lots of Pups takes a lot of work. And not necessarily the sort of work people want to do voluntarily.

mikeslr had commented on this here+
http://www.murga-linux.com/puppy/viewtopic.php?t=80680

darkcity wrote:Can the main repository handle links? That that way if something changes your can just change the link.

Im still not sure why having a mutli arch package handler would be beneficial? Wouldnt it lead to people going to the repository, selecting a package, then if its not available for there arch it would have to say "sorry not available".

The main problem, as I see it, is that maintaining a repository and testing on lots of Pups takes a lot of work. And not necessarily the sort of work people want to do voluntarily.

mikeslr had commented on this here+
http://www.murga-linux.com/puppy/viewtopic.php?t=80680

I hear ya. But what I'm talking about isn't simply a central package manager (ala PPM), I'm referring to when people post dotpet files on this very forum. If one could decrease the amount that people have to look through from perhaps 1 for each kernel and arch to 1 file that is basically just a bunch of links to those same packages, and have a package installer determining what puppy it is, what kernel it has and what arch it's on automatically, and using that information to install the specific version of the dotpet.

And as it is a set of links, all it takes to replace a dead link, is to re-upload the package to another server, and swap the first set of links with a new one, which includes the new package link.

And yes, if it does not find a package for your puppy/kernel/arch, it should tell you such, that way a simple click on this "package" which might be perhaps only a couple Kilobytes could tell you if it's available.

anyway, my two cents again.

You could always do package-$DISTRO-$ARCH, or compile on the lowest versioned system, such that it will work in all distros. For instance build against gtk+-2.10 and glib-2.12 and ssl-0.98. How do you think libflashplayer works in all distros?

technosaurus wrote:You could always do package-$DISTRO-$ARCH, or compile on the lowest versioned system, such that it will work in all distros. For instance build against gtk+-2.10 and glib-2.12 and ssl-0.98. How do you think libflashplayer works in all distros?

technosaurus wrote:How do you think libflashplayer works in all distros?

Mind blown. Newer libraries do offer new functionality and possible stability and performance increases.

package-$DISTRO-$ARCH could work very well... internally.
I'm talking about the idea of rather than looking for the "package-$DISTRO-$ARCH" for your system, downloading a file that would be a list of "package-$DISTRO-$ARCH" files, including additional links if they go down.

That way one-click install among many puppies