Petget bug

[debianfan]

Petget has a major issue, such as software:
Puppy-1.pet, puppy-ad-1.pet, puppy-af-3.pet
Wait for the same software package in the front, and the content in the front will be replaced after installation. The reason is unknown, whether it is a different version of the software or multiple branches of a certain software, installation errors will occur

[bigpup]

What is Puppy-1.pet, puppy-ad-1.pet, puppy-af-3.pet?

[debianfan]

What is Puppy-1.pet, puppy-ad-1.pet, puppy-af-3.pet?

Give an example to illustrate.
For example, if you install firefox-101 and then install firefox-101-icon, a software package with the same name as the previous one will disappear and cause errors.
Similar pet packages can cause errors during installation:
For example:
If you install chrome 102 pet and then chrome lib-103, there will be an error in the previous one

[mikeslr]

...
If you install chrome 102 pet and then chrome lib-103, there will be an error in the previous one

Patient to Dr. Kronkheit, "It hurts when I do this".
Dr. Kronkheit, "Don't do that."
Part of the skit @ https://www.youtube.com/watch?v=5_KlLzbbxJ8. Sorry, the sound could be better.

Everything involves a trade-off. AFAIK, bookworm's synaptic can be used to upgrade a Web-browser (indeed any application) but only if the earlier version was installed using synaptic or radky provided it from Bookworm's repos such that synaptic could be used to update versions and only if bookworm's repos now offers the updated version. And then, of course, you end up with only one version; the updated one.

Puppy Package Manager could never be used to 'update' an application. Unlike synaptic, PPM does not 'remove' old, no longer needed, libraries. Remember, the files from 'built-ins' are copied into RAM from READ-ONLY file-systems on storage. Depending on how the two versions are NAMED and structured, you either end up with the update (being in your SaveFile/Folder) having priority with the old version being completely ignored; two functional versions; or both versions on your Menu, but the old version now broken because it can't use the new version's libraries which have priority.

If you want more than one version of an application use portables. They are independent of each other. Most can be updated. Before updating Right-Click the folder of the old portable and select 'Duplicate'. Give the duplicate a new name. You won't be able to use the menuadd script OOTB: both verions copy identically named desktop files and create identically named and located symbolic link. You can edit the menuadd scipt (and the files it uses) or otherwise arrange for there to be differently named symbolic links and differently named and fleshed-out /usr/share/applications desktop files.

[debianfan]

...
If you install chrome 102 pet and then chrome lib-103, there will be an error in the previous one

Patient to Dr. Kronkheit, "It hurts when I do this".
Dr. Kronkheit, "Don't do that."
Part of the skit @ https://www.youtube.com/watch?v=5_KlLzbbxJ8. Sorry, the sound could be better.

Everything involves a trade-off. AFAIK, bookworm's synaptic can be used to upgrade a Web-browser (indeed any application) but only if the earlier version was installed using synaptic or radky provided it from Bookworm's repos such that synaptic could be used to update versions and only if bookworm's repos now offers the updated version. And then, of course, you end up with only one version; the updated one.

Puppy Package Manager could never be used to 'update' an application. Unlike synaptic, PPM does not 'remove' old, no longer needed, libraries. Remember, the files from 'built-ins' are copied into RAM from READ-ONLY file-systems on storage. Depending on how the two versions are NAMED and structured, you either end up with the update (being in your SaveFile/Folder) having priority with the old version being completely ignored; two functional versions; or both versions on your Menu, but the old version now broken because it can't use the new version's libraries which have priority.

If you want more than one version of an application use portables. They are independent of each other. Most can be updated. Before updating Right-Click the folder of the old portable and select 'Duplicate'. Give the duplicate a new name. You won't be able to use the menuadd script OOTB: both verions copy identically named desktop files and create identically named and located symbolic link. You can edit the menuadd scipt (and the files it uses) or otherwise arrange for there to be differently named symbolic links and differently named and fleshed-out /usr/share/applications desktop files.

Not usable, for example:
Endless sky_ 0.10.4.pet, endless sky high dpi_ 0.10.4.pet
When installing one of these two pet packages, the one in the back and the one in the front will become invalid
Unable to use normally, many software with the same name have problems

[rockedge]

I am confused as to what the bug is So you are installing via petget a package that is basically a newer (different) version of the one installed? That PPM is overwriting portions of the originally installed version rendering it inoperable?

[debianfan]

I am confused as to what the bug is So you are installing via petget a package that is basically a newer (different) version of the one installed? That PPM is overwriting portions of the originally installed version rendering it inoperable?

Pack two pieces of content yourself, pet, for example, one of them is called:
Endless sky_ 0.10.4.pet, another one is called endless sky high dpi_ 0.10.4.pet.
Install the previous one first, then the last one, and the content of the previous pet will disappear.
You can easily test it yourself to confirm that even the pet with the same name in the front will disappear during installation, and only the content of one of the several front names can be preserved.
Please give it a try and it will be clear

[mistfire]

I am confused as to what the bug is So you are installing via petget a package that is basically a newer (different) version of the one installed? That PPM is overwriting portions of the originally installed version rendering it inoperable?

Pack two pieces of content yourself, pet, for example, one of them is called:
Endless sky_ 0.10.4.pet, another one is called endless sky high dpi_ 0.10.4.pet.
Install the previous one first, then the last one, and the content of the previous pet will disappear.
You can easily test it yourself to confirm that even the pet with the same name in the front will disappear during installation, and only the content of one of the several front names can be preserved.
Please give it a try and it will be clear

That means the package name in the package metadata against package name in the installed package database was the same. PPM will simply replace the installed package with other one if the package name from the package metadata and the package name of installed package was the same. To avoid this, you must extract the pet package, edit the second column on pet.specs file with a different package name then build it as pet package again. Just renaming the filename of pet package wont work

[BarryK]

Petget has a major issue, such as software:
Puppy-1.pet, puppy-ad-1.pet, puppy-af-3.pet
Wait for the same software package in the front, and the content in the front will be replaced after installation. The reason is unknown, whether it is a different version of the software or multiple branches of a certain software, installation errors will occur

I'm running EasyOS, and petget has diverged somewhat, but is still the same principle.

I created two pets to test, and there is no problem.
Installing the testpet then testpet-other does not affect the first one.

testpet has /usr/bin/testpet script.
testpet-other has /usr/bin/testpet-other script.

[debianfan]

Petget has a major issue, such as software:
Puppy-1.pet, puppy-ad-1.pet, puppy-af-3.pet
Wait for the same software package in the front, and the content in the front will be replaced after installation. The reason is unknown, whether it is a different version of the software or multiple branches of a certain software, installation errors will occur

I'm running EasyOS, and petget has diverged somewhat, but is still the same principle.

I created two pets to test, and there is no problem.
Installing the testpet then testpet-other does not affect the first one.

testpet has /usr/bin/testpet script.
testpet-other has /usr/bin/testpet-other script.

Your two pet tests are normal, is there a problem with Bookworm Pup64's/usr/bin/makepet? Is the installation of the packaged pet using it causing an error in the approximate name?

[debianfan]

Petget has a major issue, such as software:
Puppy-1.pet, puppy-ad-1.pet, puppy-af-3.pet
Wait for the same software package in the front, and the content in the front will be replaced after installation. The reason is unknown, whether it is a different version of the software or multiple branches of a certain software, installation errors will occur

I'm running EasyOS, and petget has diverged somewhat, but is still the same principle.

I created two pets to test, and there is no problem.
Installing the testpet then testpet-other does not affect the first one.

testpet has /usr/bin/testpet script.
testpet-other has /usr/bin/testpet-other script.

Your two pets cannot be reinstalled after installation. The attachments can be reinstalled after installation. What is the error? Due to the large capacity of these two pets, they cannot be uploaded as a whole.
But the reason for the error should be in pet.specs, which was packaged with makepet. Where did it cause the problem?

[debianfan]

There is no makepet script in the easy-5.6.4 system, so it is uncertain what the reason is

Make sure it's the pet problem created by the makepet script. I used the same script from another puppy to make the pet and it worked fine

[bigpup]

This bug was reported under the Bookworm Pup64 section of the forum.

So we must assume it is a bug when used in Bookworm Pup64.

Everyone needs to be doing any testing or fixing for running in Bookworm Pup64.

In Bookworm Pup64, I know for sure that software installing is not the same as other Puppy versions.

It seems to be more setup to supporting apt for doing software downloads and installs.

[radky]

Pack two pieces of content yourself, pet, for example, one of them is called:
Endless sky_ 0.10.4.pet, another one is called endless sky high dpi_ 0.10.4.pet.
Install the previous one first, then the last one, and the content of the previous pet will disappear.

@debianfan

The dir2pet utility creates metadata for the pet.specs file, such as the following for your two example packages:

package1: endless-sky_0.10.4.pet
package1 pet.specs: endless-sky_0.10.4|endless|sky_0.10.4||BuildingBlock|0K||endless-sky_0.10.4.pet||no description provided||||

package2: endless-sky-high-dpi_0.10.4.pet
package2 pet.specs: endless-sky-high-dpi_0.10.4|endless|sky-high-dpi_0.10.4||BuildingBlock|0K||endless-sky-high-dpi_0.10.4.pet||no description provided||||

When dir2pet creates a new pet package from a source directory that has no prior pet.specs file, a new pet.specs file is created and dir2pet assumes the hyphen character (-) will separate the 2nd field (nameonly) from the package version number.

However, in your examples above, the source name uses the underscore character (_) preceding the version number. Consequently, in your case, dir2pet incorrectly identifies the 2nd field (nameonly) of package1 and package2. Specifically, the 2nd-field metadata (endless) is identical for package1 and package2 -- and this may confuse the Puppy Package Manager when you install both package1 and package2.

To avoid the confusion, when creating new pet packages from source, please use the hyphen character (-) to separate the source name and version number (and in your examples above, make sure you have removed the old corrupt pet.specs files which have identical 2nd-field metadata).

Please recreate the pet packages after you (1) rename the source directories as shown below and (2) remove the old corrupt pet.spec files:

endless-sky-0.10.4
endless-sky-high-dpi-0.10.4

[debianfan]

Pack two pieces of content yourself, pet, for example, one of them is called:
Endless sky_ 0.10.4.pet, another one is called endless sky high dpi_ 0.10.4.pet.
Install the previous one first, then the last one, and the content of the previous pet will disappear.

@debianfan

The dir2pet utility creates metadata for the pet.specs file, such as the following for your two example packages:

package1: endless-sky_0.10.4.pet
package1 pet.specs: endless-sky_0.10.4|endless|sky_0.10.4BuildingBlock|0Kendless-sky_0.10.4.petno description provided||

package2: endless-sky-high-dpi_0.10.4.pet
package2 pet.specs: endless-sky-high-dpi_0.10.4|endless|sky-high-dpi_0.10.4BuildingBlock|0Kendless-sky-high-dpi_0.10.4.petno description provided||

When dir2pet creates a new pet package from a source directory that has no prior pet.specs file, a new pet.specs file is created and dir2pet assumes the hyphen character (-) will separate the 2nd field (nameonly) from the package version number.

However, in your examples above, the source name uses the underscore character (_) preceding the version number. Consequently, in your case, dir2pet incorrectly identifies the 2nd field (nameonly) of package1 and package2. Specifically, the 2nd-field metadata (endless) is identical for package1 and package2 -- and this may confuse the Puppy Package Manager when you install both package1 and package2.

To avoid the confusion, when creating new pet packages from source, please use the hyphen character (-) to separate the source name and version number (and in your examples above, make sure you have removed the old corrupt pet.specs files which have identical 2nd-field metadata).

Please recreate the pet packages after you (1) rename the source directories as shown below and (2) remove the old corrupt pet.spec files:

endless-sky-0.10.4
endless-sky-high-dpi-0.10.4

I usually use makepet, which can be directly packaged in a folder. Do you have an updated and improved makepet?

[radky]

I usually use makepet, which can be directly packaged in a folder. Do you have an updated and improved makepet?

@debianfan

In BW64, you can easily create a pet package by using the ROX right-click menu:

Specifically, in ROX-Filer, simply right-click the source directory which will be included in your pet package, then click the dir2pet context menu option and fill in the popup dialog box (Package database-entry creator).

--

Alternatively, BW64 also includes the small makepet script (created by forum member Stu90) which functions as a simple wrapper script that redirects the input source directory to the comprehensive dir2pet utility for creation of the pet package.

If the makepet wrapper script is your preference, simply use ROX-Filer to drag-and-drop /usr/bin/makepet onto the desktop. Then you can drag-and-drop your source directory onto the desktop makepet icon. This will call dir2pet to create the pet package.

[mikeslr]

This is not unique to Bookworm. And I wouldn't call it a bug; but it is an inconvenience which you have to know about and overcome.

When a pet is created within that pet is a file named pet.specs. If, in creating a pet using a pet which already has a pet.specs file --whether updating or as a template-- you fail to delete the existing pet.specs file it will be used "AS-IS" by the new pet. This may or may not result in an installable pet. But among the other problems this generates is that the new pet can not be used in applications such as PaDS, https://www.forum.puppylinux.com/viewto ... 6355#p6355 which use the 'arguments' in pet.specs to combine pets.

The issue isn't encountered when creating pets 'from scratch': no existing pet.specs file.

The workaround is "Don't do that": i.e. delete the existing pet.specs file before using makepet or dir2pet. But it would be better if there were a line or two in dir2pet and makepet which tested for the existence of a pet.specs file and finding one deleted it before creating the new pet.