Puppy Linux Discussion Forum

amigo · Joined: 02 Apr 2007 Posts: 1776

Of course, that is not what I meant -that would lead to huge duplication of libs and giant packages. The solution is a package format which follows reasonable standards and a package manager smart enough to know where it installs every file from a package, is able to remove those same files when necessary or upgrade them. The current system is only able to 'upgrade' by forcefully installing a new version of a program or libs over the old one -and as pointed out before, it does nothing about any leftover files from the old version.

BTW, it is not just simply about tracking the program version -you also need a 'build' or 'release' number which accounts for re-builds of the same prog/lib version. For instance, when a package is incorrectly built, you should be able to rebuild the package (correctly now) and it have a new 'build' number which would clearly indicate that it is newer than the old one and be upgradable. Also, if puppy is ever to be available for other architectures besides x86_32, then packages should also have an indication of which architecture they are for.

In light of these considerations, the present system clearly fails on every point. A complete re-think is needed, starting with the format of the package -but taking into consideration all implications of repo-management, upgrading/downgrading, possible dependency management(the most difficult aspect of all -along with complete system upgrades). There is a great need for consistency in packing, which implies a standard way of creating packages, and/or a great package 'lint' program which can inspect and/or correct defective packages. But, I'm preaching to the choir here, or am I?

jpeps · Joined: 31 May 2008 Posts: 2449

It's also nice to have a list of built-in files that can be compared with a pet's files before installing/uninstalling it. This generates one in /mnt/home:

amigo · Joined: 02 Apr 2007 Posts: 1776

There should be *no* 'built-in' files. Every file should be part of a single package which can be installed, removed upgraded, etc. It seems like a good idea, jam a bunch of stuff into a single image and call it a 'base' installation, but that concept is at the core of the problem with puppy package management -how can you manage these built-ins? We have had a special program which could remove parts of the base, but why have a special program to do it at all? A simple list of all the base files doesn't help when we want to remove coherent parts of that base, update it or whatever. Everything should simply be part of an individual package to keep track of it. There should only be very limited exceptions to that 'rule' -as said before, many packages contain a script which should be run before or after installation or removal of the package. They commonly create links and sometimes even directories, but they should not create any files. In short, any actions taken by scripts during installation should be accountable (reversable if needed) when the package is removed.
The whole approach of a main 'blob' of content with only extras as packages just is not workable. I know that my saying so will only make those who believe in that system try even harder to make it work -more complex, hackish workarounds to cover up a fundamental design error.

8-bit · Joined: 03 Apr 2007 Posts: 3033 Location: Oregon

jpeps · Joined: 31 May 2008 Posts: 2449

8-bit · Joined: 03 Apr 2007 Posts: 3033 Location: Oregon

I want to confess!
When I made a PET for system_info, I was very tired and all the things I should have checked never happened.

So, when creating a Pet Package, be sure to check it out on Puppy booted with "pfix=ram".
In doing so, I discovered that Puppy Lucid 520 does not have "zenity" or "sensors" as well as supporting files for them.
And that means I must have installed them either through an update or as a pet or tar.gz and forgot about it.

So I learned a lesson.
Always, always check your Pet on Puppy booted with "pfix=ram".

That is because trying to remember everything you installed is almost impossible.

Flash · Posted: Mon 08 Aug 2011, 21:30 Post subject:

8-bit, is that bit of wisdom to be found anywhere in the various threads and Wiki articles that describe how to make a .pet for Puppy?

8-bit · Joined: 03 Apr 2007 Posts: 3033 Location: Oregon

Flash,
Thank you for letting me know what I should have known all along.
As if I do not feel bad enough at myself for not following instructions and other posts about PET creation.
At any rate, I apologize to all that this may have created a problem for!

Flash · Posted: Mon 08 Aug 2011, 23:59 Post subject:

I wasn't trying to make you feel bad. I thought you did a good thing! Very Happy

Booting Puppy from a CD with pfix=ram in order to check for dependencies sounds to me like a simple and easy way to insure your .pet will work for everyone who uses that version of Puppy.

jpeps · Joined: 31 May 2008 Posts: 2449

8-bit · Joined: 03 Apr 2007 Posts: 3033 Location: Oregon

An uninstall of that PET would answer the question as to if built in files would get deleted.
In my case, I assumed, mistakenly, that zenity was a bulit in file in Lupu 520. After booting it with "pfix=ram" I found out it was not.
So from now on, I am going to check PETS I write by booting with "pfix=ram" and see what dependencies it needs that are not in the built in files.

Also, since zenity, although still being supported by the developers, now requires an updated gtk 3.0 to compile, I am going to recommend yad with a system link to it called zenity.

There are a few users that have downloaded and installed the system_info.pet package I made and so far, other than one user not having a system link to gtkdialog3 of gtkdialog, and another that requested a smaller window version for his smaller screen resolution, I have received no further feedback.
I can also say the same for a specialized utility I created to format both USB and internal floppy disks.
So I will remember to check and double check any Pet packages I make to see if I can crash them before releasing them.

jpeps · Joined: 31 May 2008 Posts: 2449

8-bit · Joined: 03 Apr 2007 Posts: 3033 Location: Oregon

I have a little utility called "unzipper_dragndrop" that wil make a directory with the same name as a PET and uncompress the PET to that directory. It helps me to see what is in a PET before installing it.
I guess one thing I would like to see is an option in Puppy Package Manager to be able to download a PET without installing it.
It seems that every time I try out a new Puppy version, I am installing the same PET packages.
If I have the option to just download the PET, I can use it later and save the bandwidth it takes using Puppy Package Manager to install them each time.

jpeps · Joined: 31 May 2008 Posts: 2449

puppyluvr · Posted: Tue 09 Aug 2011, 08:42 Post subject:

Hello,
I rename every package *.tar.gz, and unpack it into a directory, and have a look inside, before I install it..

Couldnt the PPM parse /root/.packages and compare against a list of builtins before uninstalling?

@8-bit..
I once released a remastered Puplet..
In short order, a user emailed me..
From my account, to explain that I should clean things up a bit before releasing... Embarassed

Live and learn.. Wink