Puppy Linux Discussion Forum

[8-bit]

It seems to be common practice to make a pet with dependencies offered in an additional package.
Also, if those dependencies already exist in Puppy, an uninstall removes them and possibly breaks other applications.

I have a solution that I have not seen done and have tried it on my own computer.
I found that the /root/my-applications/bin and ....lib directories are in Puppy's path.
So I tried making a Pet with all needed dependencies and had it install in the /root/my-applications directory.
The advantage to this is that an uninstall of the Pet package will remove the library files and supporting binary files in /root/my-applications and not wipe out supporting files needed by other applications.
Also, all dependencies can be part of the package.
As of yet, I have not seen any Pet packages constructed to install this way.

So what do you think, is this a good idea or not?

[puppyluvr]

Hello,
Well, other than it being blasphemy to install anything in /root..
I believe that is what those directories are designed for..

Generally, if a package I release requires libs that may/may not be in an intended users Puppy, I will post the libs separately.
Uninstalling the package via the PPM leaves the separate libs intact.

Another option is to have the package keep its dependencies in a directory, and link them to /usr/lib.. Then, uninstalling the package removes the directory, and the links but leaves the rest of the libs intact...

I`m becoming convinced that ALL packages should install to /mnt/home, and link themselves into the path.. Keep the savefile light that way... Been doing Firefox and Wine that way for years.. Plus, that way programs can be shared amongst various frugal Puppies...

[8-bit]

The point I was trying to make is if a pet is made to put it's needed library files into /root/my-applications/lib, they are then completely isolated from the normal library directories and no links are required for them.
Also, uninstall of a PET removes them while not touching the main library files.
So if a pet is created that has library files that already exist in the Puppy version, installing them in /root/my-applications/lib will not hurt anything and a uninstall will remove them without removing the main library ones.
If you want an example, the system_info.pet I made, installs supporting libraries to /usr/lib. And some Puppy versions do not have those files.
But if a Puppy version has them by design, uninstalling the PET removes those libraries and a binary expecting them does not run.

[darkcity]

i believe GoboLinux does something similar
http://www.gobolinux.org/


There's a GoboPuppy at (under Hungarian Versions)
http://puppylinux.org/wikka/PuppyVersion

[amigo]

Brain-dead package management... that's the problem.

[Flash]

[darkcity]

what about pussy linux?

[8-bit]

There are just too many pet packages to do a rewrite of all of them.
But if Puppy Package Manager got a rewrite to check a built-in list of libraries and not remove one that was included in a Pet Package uninstall, the base libraries would stay intact and files in them would not get removed on an uninstall of a PET.

If you can think of another way that one could include needed library files of a Pet in it and not have them removed on uninstall of the PET if they were base library files I am open to suggestions.
I do not know how much additional room in an ISO a list of the base library files would take, but it is a start at a fix of Puppy Package Manager that would protect the base library files on an uninstall.
This could be done with a check of the library file(s) that was to be removed against the base list. If the library file was not found in the list, it would be removed.

[chiron]

I would not use a list of the base library files, since there also could be libraries installed by other pets previously, which are then removed, rendering the other previously installed programs infunctional.
I'd rather think of a list that is created upon installing, holding all the pre-existent files. Upon uninstalling, those files would not be deleted but simply left in place.

[jpeps]

I thought this was what /usr/local/lib was about.

[rcrsn51]

[bigpup]

[8-bit]

Ok, you want an example.
When I created a PET package for system_info.sh, I wanted users of Puppy 4 versions to be able to use the system utility also.
One of the buttons called a binary named "sensors" that is part of Lucid 520, but does not exist in the Puppy 4 versions and some of the other Lucid versions.
That binary also requires some supporting library files that do not exist in other versions of Puppy.
So I included the binary and supporting library files in the PET.
The Problem arises when the PET is uninstalled on a version of Puppy that does contain those files.
The uninstall removes the files and as a result, breaks the "sensor" binary.
On a version of Puppy that does not contain those files, an uninstall makes no difference.

What I was trying to do though is to make the PET without having to have an additional package of support files.

[amigo]

Any proper package manager should maintain a list of files installed by each *package* -every file on the system should be accounted for in this way -with limited exceptions. Many packages include one or more scripts which perform some action pre/post install and pre/post removal -typically the creation of links(since links are best not included in the package archive itself). So, when the package manager is asked to remove a package, it should check against the database of all files in all packages, and not remove any files, links or directories which belong to another package.

In 8-bit's case, it sounds as if the package manager (sic?) is simply searching for a file named 'sensors' and is removing the one listed by the database instead of the one under his 'proprietary' directory -as if it can't tell the difference between /root/my-applications/bin/sensors and /usr/bin/sensors. It's rocket science to do such a thing, of course...

Of course, any package manager that has to deal with an unlimited number of possible paths where any sort of thing might be located has it tough. Good package management is an after-function of good package creation, which is an after-fuction of properly-located resources. Until pets have no sanity about their paths, there can be no sane package management -much less repo-management -which is completely different. Each of these factors has to be considered properly and ealt with in a predictable manner before any sort of management can be attained.

'ALL packages should install to /mnt/home'
'/root/my-applications/bin'
/usr/local/share/proggie/shared/binaries/bin/proggie (which is actually a link to):
/home/mnt/round/robins/barn/local/yokels/my-sfs/boot/mount/shared/local/bin/shared/my-proggie/bin/proggie
Then it turns out that /home/mnt/round/robins/barn/local/yokels/my-sfs/boot/mount/shared/local/bin/shared/my-proggie/bin/proggie is really a 'wrapper' which cd's into /usr/local/share/proggie/libs/bin/proggie and executes the 'real' proggie.

Do you see the problem? And I've seen folks hear complain about how complicated the 'normal' Linux filesystem structure is! However, it even includes a sepcification and location for just such programs to happily live: /opt
Every program under /opt should have its' entire contents under a *single* directory and can do anything it likes under that dir. It even allows for having multiple versions of the same lib or program concurrently installed.

Ah, someone mentiond /usr/local/lib. /usr/local should be delivered emtpy when a distro is installed or booted the first time -it does include a directory structure but should ahve *no files*. That is where the end user can copy scripts and things which are not packaged, and where they can and should install things which they have 'locally compiled*. It is quite common to mount /usr/local on a separate partition or hard drive so that ones' locally-maintained files are completely separated from their main partition -so they are completely and uniquely portable to another machine and not touched at all by any upgrades or breakage of the main system. *Packaged software* should never go under /usr/local. Executable files, programs and data should never go under /root or under any users HOME directory. Sources or packages which install or directly alter any files in anyones HOME dir are completely evil and unmanageable.

There are very good reasons for the existence and use of the 'standards'. Only by understanding them and accepting the validity of all the experience they represent can an even half-hearted attempt at package management be made. Being different just for its' own sake just won't cut it. The 'complexities' of running from a LiveCD, a frugal install, being modular or running by default as root -none of these present any problem whatsoever which has not been thouroughly thought out and implemented in sane ways -before puppy ever came along. Always re-inventing the wheel is a waste of resources.

[Flash]

Thank you, amigo. I agree, the solution is to give every application its own directory which also contains all the dependencies the application needs.