PPM2

[mavrothal]

I can not reproduce this.

Selected configure.
Went to options tab.
clicked do not show terminal actions
went to update tab
clicked update now
the yellow terminal came up asking to update the repos
closed the terminal (no updates)
Clicked "OK" on the configure window.
PPM restarted with everything OK.

1-5-same..

6th step-no yellow terminal,nothing happened...,waited for some time,closed ppm and restarted ppm..

repo's were deselected..could not reselect them and no updates..

These are the steps I did ,didn't do anything else ..

As I described above, I can not reproduce it.
As a matter of fact the "do not show terminal activity" option and the yellow update terminal, are totally unrelated. The update process itself is performed by the 0setup script that was never changed in PPM2.
You can just run

Code: Select all

rxvt -bg yellow -title "download databases" -e /usr/local/petget/0setup

to see it going.

To make the databases disappear you have to start the update process (by opening the "yellow" terminal and pressing enter) and then interrupt it before it finishes. Any chance that the terminal open behind some other window or minimized or something and you missed it?
Is it happening again if you repeat the process? ie the "yellow" terminal never appears?

Anyway, if the Packages-puppy-* files are missing from /root/.packages you can copy the files from the main sfs (/initrd/pup_ro2/root/.packages) and try the update again.

[john009]

Anyway, if the Packages-puppy-* files are missing from /root/.packages you can copy the files from the main sfs (/initrd/pup_ro2/root/.packages) and try the update again.

Thanks mavrothal.that worked;updated ppm and everything is A-okay..

ppm is now a lightweight synaptic ,Itś really good..

john009

[scsijon]

Just came across this, looks nice but 5 faults for you to start with.

Working with 5.5.1. and todays d/l. ppm_auto.2.pet

Open to full screen:

1- go up to the 'Packages to Install' - it's marked out with two horizontal lines - pass over these with the mouse and the lines disapear, even though you've done nothing.

2- Description doesn't / won't extend to the right, although the size for 'Repository' is now enormous and a number of items under Description extend beyond it's field boundary.

3- When opening it shows for the first repository of your 'ticked set', not the last one you left it on when last closing PPM2.

4- When restarting after closing it reopens as a small window, even if you closed it as a full window.

5- When installing it, it says it's being installed to Utility, not Setup where PPM lives. Confusing to new users and those new to adding packages.

Sorry, but going back to the old one, i'll check back later though when you have things sorted out

} ain't bugs fun

[mavrothal]

Working with 5.5.1.

Thanks for testing, particularly in such an old build.
Is 5.5.1 what?

1- go up to the 'Packages to Install' - it's marked out with two horizontal lines - pass over these with the mouse and the lines disapear, even though you've done nothing.

I do not remember having seen that. And I can not reproduce it. Maybe is puppy/hardware specific. Also is not clear to me what "two horizontal lines" means. Maybe a screeny will help.

2- Description doesn't / won't extend to the right, although the size for 'Repository' is now enormous and a number of items under Description extend beyond it's field boundary.

Sorry. I'm the "visual" type A screeny would be again helpful here but I can not see any truncation of the description field (if that's what you mean). If you suggest that the description window should auto-resize at the expense (up to a limit) of the repository window, that is a design limitation. The 2 windows have a fixed width ratio. Not sure if gtkdialog can do what you suggest though, and I'm certainly sure that I can not. Have you seen that in any other gtkdialog app? We welcome pointers or better yet, patches (or bug Zigbert )

3- When opening it shows for the first repository of your 'ticked set', not the last one you left it on when last closing PPM2.

This is not what I see. Besides, if you open the configure window, change the "ticked" repositories and press OK, PPM will automatically restart and have the new set, which remains through restarts till further change. Isn't it what you get? If you change the repos and close the window without pressing OK, will (correctly) be considered as a cancelled operation and will be discarded.

4- When restarting after closing it reopens as a small window, even if you closed it as a full window.

PPM design (original or new) does not include an "rc" file, where current UI variables could be written. So it always opens to the configured settings. "Full screen" is not a configurable option at this point.
Maybe PPM3 should use an "rc" file.

5- When installing it, it says it's being installed to Utility, not Setup where PPM lives. Confusing to new users and those new to adding packages.

PPM in general assigns things to "Utilities if there is not a *.desktop entry to specify otherwise. The PPM2 pet does not have a desktop entry since this file is not changed from the original. Maybe I'll add one. But I wouldn't wary about that as PPM suppose to be built-in and not an installable package. It is already in woof-CE.

Sorry, but going back to the old one, i'll check back later though when you have things sorted out

This may take a really long time... But which of the above is a feature that the old one has?

[stemsee]

Really the gui of ppm-2 + should not have the text 'Install' on the button, it would be better for newbies if it said 'DO It' or 'Execute' because if you select download (only) then it isn't installing, and noobs might feel stressed at the apparent dilemma.

[mavrothal]

Really the gui of ppm-2 + should not have the text 'Install' on the button, it would be better for newbies if it said 'DO It' or 'Execute' because if you select download (only) then it isn't installing, and noobs might feel stressed at the apparent dilemma.

You probably have an older version. It has "DO it!" since version 1.9.7

[stemsee]

Oh! ha ha. I m using 1.9.5 ... Oops!

[ASRI éducation]

I use the latest version of PPM2 for three weeks.
Everything works great.
This version is obviously going to be added to the French puplets: Toutou, ASRI, ToOpPy, etc.
Regards,

[mavrothal]

This version is obviously going to be added to the French puplets,

You may want to consider some additional changes currently in woof-CE
https://github.com/puppylinux-woof-CE/w ... 56a1e14275
https://github.com/puppylinux-woof-CE/w ... 9ca75b50bb
https://github.com/puppylinux-woof-CE/w ... 4e8216f6f7

[ASRI éducation]

This version is obviously going to be added to the French puplets,

You may want to consider some additional changes currently in woof-CE
https://github.com/puppylinux-woof-CE/w ... 56a1e14275
https://github.com/puppylinux-woof-CE/w ... 9ca75b50bb
https://github.com/puppylinux-woof-CE/w ... 4e8216f6f7

Thank you for this advice.
I will integrate the three files that you propose.
Regards

[slavvo67]

3 or 4 of my pets would no install using PPM2 due to "the file name inside the pet not matching the pet name." Of course, I fixed the pets but I question the need for such a feature.

Slavvo67

[gjuhasz]

Everything works great.

I propose a small fix that provides a last check before deleting files shared by multiple packages.

Around Line 87 of /usr/local/petget/removepreview.sh, instead of:

Code: Select all

rm -f "$ONESPEC"

I propose this:

Code: Select all

vajonkelle="$ONESPEC"; [ ! `grep $vajonkelle /root/.packages -R | grep ".files" | grep -v "${DB_pkgname}"` ] && rm -f "$ONESPEC"

I attach the fix in a form of a pet file.


Have fun!

Regards,

gjuhasz

[mavrothal]

Code: Select all

vajonkelle="$ONESPEC"; [ ! `grep $vajonkelle /root/.packages -R | grep ".files" | grep -v "${DB_pkgname}"` ] && rm -f "$ONESPEC"

The code as written also detects $ONESPEC incidences in /root/.packages/builtin_files. Is this the intention? If yes why?
If not you may want to omit "-R" or grep for '\.files'

However, if indeed 2 different installed packages have installed the same file should first verify which one is the latest looking at the time stamp of the respective "*.files" file. If indeed the other incidence is coming from a package installed later should leave it alone I guess.

Of course we should not have 2 packages installing the same files and usually distro packages do not do that, but pets can be crude I guess.
BTW do you have a use-case/example indicating the need of the discussed changes?

Latter: here is a patch that will remove the $ONESPEC only if is the latest version.

Code: Select all

--- a/usr/local/petget/removepreview.sh	2015-04-20 14:45:10.666670932
+++ b/usr/local/petget/removepreview.sh	2015-05-07 10:54:08.003280299
@@ -85,7 +84,21 @@
       [ -f "/initrd${SAVE_LAYER}${DN}/.wh.${BN}" ] && rm -f "/initrd${SAVE_LAYER}${DN}/.wh.${BN}"
      fi
     else
-     rm -f "$ONESPEC"
+     OTHERPKG=$(grep "${ONESPEC}" /root/.packages/*.files | grep -v  "${DB_pkgname}")
+     if [ "$OTHERPKG" != "" ]; then
+      rm -f /tmp/LIST
+      for f in $(grep "${ONESPEC}" /root/.packages/*.files | cut -f 1 -d ':' |sort |uniq)
+      do
+       MOD=$(stat $f | grep 'Modify:'|cut -f 2-10 -d ':')
+       FILE=$(stat $f | grep 'File:'|cut -f 2 -d ':')
+       echo $MOD $FILE >> /tmp/LIST
+      done
+      [ "$(cat /tmp/LIST | sort |tail -n1 | grep "${DB_pkgname}")" != "" ] \
+       && rm -f "$ONESPEC"
+      rm -f /tmp/LIST
+     else
+      rm -f "$ONESPEC"
+     fi
     fi
    fi
   done

However, can still generate problems if indeed bad packaging just installs the same files twice. The package left behind will be non-functional.
Leaving $ONESPEC always in can also generate problems if versions are incompatible so the package left behind will also be non-functional.

For example "good_app" installs /usr/bin/execute_this. The you install "bad_app" that also installs an incompatible version of /usr/bin/execute_this and breaks "good_app". No matter what you are scr***d.
Ideally, neither "good_app" nor "bad_app" should install /usr/bin/execute_this if it is a dependency. They should just require the dependency to be installed. Not include it.

In sort, there is not really any good solution for bad packaging and I do not think we should go to any great length to support it as it is only going to generate problems down the road.
But, the patch is there if you want it

[gjuhasz]

If indeed the other incidence is coming from a package installed later should leave it alone I guess.

Of course we should not have 2 packages installing the same files and usually distro packages do not do that, but pets can be crude I guess.
BTW do you have a use-case/example indicating the need of the discussed changes?

I fully agree that pets can be crude. However, I don't think the order of installation would really determine either the uninstall order or the importance of the pet packages.
In most cases - feel free to kill me if I am wrong - the users try out the interesting pets they find in the forum. Sometimes, those pets "mimic that they are portable" means their creators gather the necessary libs for their favorite puplet. Then another forum member adds another lib requested by another puplet, and so on. Finally, a working package is available (as a result of the dir2pet script) without any / without correct references to dependencies. It is a funny thing that these pets can coexist but uninstalling one of them results crashes in the rest.
I have a bad experience with various pets containing Python modules, .so files, etc.

I attach a couple of example pets that share one file. No specific functions expected, handle them only as examples. You can install them in any order then uninstall them in any order. See how the content of /root/valami changes without/with my fix applied.

Have fun!

Regards,

gjuhasz

[mavrothal]

It is a funny thing that these pets can coexist but uninstalling one of them results crashes in the rest.

When the files that a clobbered are the same version this will happen.
However, when the new files are of an incompatible version then this breaks the old one.
An alternative is when a file is clobbered to be saved and and reinstated when the new pet is removed. Installpkg.sh and removepreview.sh already have the relevant code but is for full installs only.
With a bit of work could be made to work in other modes and check pup_rw or pup_ro1 instead.
I do not know if I'll have this kind of time so please provide a patch if you want to try it and get there

[stemsee]

Hi Mavrothal
I hope to get your advice.
I am using this simple code

Code: Select all

#!/bin/sh
if [ ! -z "$2" ]; then
nm="$2"
else
. /tmp/name
fi
while read line
do
lined=`echo $line | rev | cut -f2,3,4,5,6,7,8,9,10,11,12,13,14 -d '/' | rev`
mkdir -p $HOME/"$nm"/"$lined"
cp -f $line $HOME/"$nm"/"$lined"/
done < "$1"
rox $HOME/"$nm" &

to create an apptree of any installed app. Which I can then right click and create a pet package. I simply open term and type

Code: Select all

apptree $HOME/packages/builtin/hiawatha.files hiawatha-1.5

for example and seems to work fine. Is there anything else obvious that may be missing?

Together with slocategui i can build a similar apptree but with only those elements dirs/files which share the search term. Which seems to be ok for transferring principle parts of apps.

Thanks
stemsee

[mavrothal]

I am using this simple code

I do not know how this relates to PPM(...) but it looks OK. However, modifications done by install scripts will be missed.

[stemsee]

Isn't ppm responsible for ~/.packages/* and ~/.package/builtin/*

Ah yeah! pinstall files, well spotted. Maybe ppm should back up pinstall files during install into an lz4 compressed archive for later use! That would be awesomeness personified!

[mavrothal]

Maybe ppm should back up pinstall files during install into an lz4 compressed archive for later use!

Install scripts are run during woof building by 3builddistro.

[mavrothal]

In most cases - feel free to kill me if I am wrong - the users try out the interesting pets they find in the forum.

So here is a patch for these adventurous puppians

Code: Select all

--- a/usr/local/petget/removepreview.sh	2015-04-16 08:32:03.626402670 +0300
+++ b/usr/local/petget/removepreview.sh	2015-05-09 09:01:47.643136701 +0300
@@ -85,7 +85,23 @@
       [ -f "/initrd${SAVE_LAYER}${DN}/.wh.${BN}" ] && rm -f "/initrd${SAVE_LAYER}${DN}/.wh.${BN}"
      fi
     else
-     rm -f "$ONESPEC"
+     cd /root/.packages
+     grep "${ONESPEC}" *.files | grep -v  "${DB_pkgname}" | cut -f 1 -d ':' | sed s'/\.files//' \
+     > /tmp/pets_with_common_files
+     cd -
+     for LINE in $(cat /tmp/pets_with_common_files)
+     do
+      [ "$(grep $LINE /tmp/pkgs_to_remove)" != "" ] && \
+       sed -i "/$LINE/d" /tmp/pets_with_common_files
+     done
+     OTHERPKG=$(cat /tmp/pets_with_common_files)
+     if [ "$OTHERPKG" ];then
+      OTHERPET=$(echo ${OTHERPKG} | tr ' ' ',')
+      . /usr/lib/gtkdialog/box_yesno "$(gettext 'Puppy Package Manager')" "$(gettext 'It appears that the') <b>${ONESPEC}</b> $(gettext 'file installed by the ') <b>${DB_pkgname}</b> $(gettext 'package you are removing,') <b> $(gettext 'was also installed by the') ${OTHERPET} $(gettext 'package(s)! ')</b> $(gettext 'This is likely because of some careless package generation but removing the file may break the other package(s). Do you want to remove it anyway?')"
+      [ "$EXIT" = "yes" ] && rm -f "$ONESPEC"
+     else
+      rm -f "$ONESPEC"
+     fi 
     fi
    fi
   done

Will generate a warning as shown.
However, I do not intend to put it in woof since grep'ing and sed'ing through all your installed files can slow down the remove process significantly as install packages increase.