PPM is too secretive

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PPM is too secretive

JakeSFR
I'm wondering why PPM neglects to show lots of 'BuildingBlock' apps (vim, tree, sox - to name just a few)?
Yes, they can be found via 'find' field, but first a user must know what (s)he's looking for.
Has it been purposely omitted??

I've added BB category to ui_Ziggy and ui_Classic, and gained access to hundreds of previously hidden pkgs:

--- /initrd/pup_ro2/usr/local/petget/ui_Ziggy	2014-01-11 12:27:01.000000000 +0100
+++ ./ui_Ziggy	2014-04-14 17:53:51.656577093 +0200
@@ -17,7 +17,7 @@
 ALLITEM='' ; ALLSTOCK='' ; CATHEIGHT='100' ; WINHEIGHT='380'
 if [ "$ALLCATEGORY" != "" ];then
  ALLITEM="<item stock=\"gtk-ALL\">$(gettext 'ALL')</item>"
- ALLSTOCK='stock["gtk-ALL"] = {{ "pet24.png", *, *, *}}'
+ ALLSTOCK='stock["gtk-ALL"] = {{ "pet48.png", *, *, *}}'
  CATHEIGHT='112'
  WINHEIGHT='388'
 fi
@@ -43,6 +43,7 @@
 Internet:$(gettext 'Internet')
 Multimedia:$(gettext 'Multimedia')
 Fun:$(gettext 'Fun')
+BuildingBlock:$(gettext 'BuildingBlock')
 ALL:$(gettext 'ALL')"
 echo "#!/bin/sh
 CATTRANSTABLE='${CATTRANSTABLE}'" > /tmp/ppm-ui-ziggy-fix
@@ -171,6 +172,7 @@
    <item stock=\"gtk-Internet\">$(gettext 'Internet')</item>
    <item stock=\"gtk-Multimedia\">$(gettext 'Multimedia')</item>
    <item stock=\"gtk-Fun\">$(gettext 'Fun')</item>
+   <item stock=\"gtk-BB\">$(gettext 'BuildingBlock')</item>
    ${ALLITEM}
    <width>140</width><height>${CATHEIGHT}</height>
    <action signal=\"changed\">/tmp/ppm-ui-ziggy-fix \$CATEGORY | xargs -I CATINSERT /usr/local/petget/filterpkgs.sh CATINSERT</action>
@@ -225,6 +227,7 @@
 	stock["gtk-Internet"] = {{ "www48.png", *, *, *}}
 	stock["gtk-Multimedia"] = {{ "multimedia48.png", *, *, *}}
 	stock["gtk-Fun"] = {{ "games48.png", *, *, *}}
+	stock["gtk-BB"] = {{ "pet48.png", *, *, *}}
 	'${ALLSTOCK}'}
 class "GtkWidget" style "icon-style"' > /tmp/puppy_package_manager/gtkrc_ppm
 

--- /initrd/pup_ro2/usr/local/petget/ui_Classic	2014-01-11 12:27:01.000000000 +0100
+++ ./ui_Classic	2014-04-14 18:25:32.859885550 +0200
@@ -46,6 +46,7 @@
    <radiobutton><label>$(gettext 'Internet')</label><action>/usr/local/petget/filterpkgs.sh Internet</action><action>refresh:TREE1</action></radiobutton>
    <radiobutton><label>$(gettext 'Multimedia')</label><action>/usr/local/petget/filterpkgs.sh Multimedia</action><action>refresh:TREE1</action></radiobutton>
    <radiobutton><label>$(gettext 'Fun')</label><action>/usr/local/petget/filterpkgs.sh Fun</action><action>refresh:TREE1</action></radiobutton>
+   <radiobutton><label>$(gettext 'BuildingBlock')</label><action>/usr/local/petget/filterpkgs.sh BuildingBlock</action><action>refresh:TREE1</action></radiobutton>
    ${ALLCATEGORY}
   </vbox>
   <vbox>

(There are also some leftovers of 'ALL' category, but when enabled it shows items from all categories + those unlisted, so I didn't find it too useful.)



Anyway, much better solution would be to force showing of all those apps in _appropriate_ categories (vim -> Documents, tree -> Filesystem, etc.), but that's a task for someone who's familiar with PPM's internals more than I am...

Greetings!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

Karl Godt
Administrator
Tja, then it needs to create a huge VARIABLE and

VARIABLE="$BB
$FUN
$ETC"

ALL_REST=`echo "$ALL" | /bin/grep -v "$VARIABLE"`


Note : busybox grep -v "$LIST" unfortunately does not work like the grep binary , therefore /bin/grep .


Idea of mine would be to put all binaries and scripts
to /usr/bin and /usr/sbin
and keep /bin and /sbin for busybox applets .

Or configure BB using applets first .
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

bigpup
In reply to this post by JakeSFR
While you are changing PPM.

The setting for what you see in the package lists.

I feel the default setting for package types should be:

any type

EXE

Someone new to Linux is not going to really understand all of these package types options.
In fact, I do not understand most of them.
Look at the pull down list of possible package  types and tell me you understand what each one is.

Really!

Try to find something like a graphics hardware driver when the package types is set to something other than

Any type

EXE

Would also be good to have

EXE
Dev
Doc
NLS

Selected by default, just to eliminate that confusion.

Options are good to have, but only if you understand what those options are going to do.
For most people they probably will not know.
Not good or bad, just a fact of life.
Most users do not understand or want to understand the inner workings.
They just want it to work.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

bigpup
In reply to this post by JakeSFR
Does PPM really need to be limited to only showing a max of 5 repositories?

For Classic view,

 I can see a problem, because the list of repositories is at the top of the GUI is in a single row.
5 repositories is about all you can put there.

Any reason they could not be shown, in two rows, in the top of the classic GUI?

Or

Have the window size auto adjust to what space is needed to display complete GUI.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

JakeSFR
@Karl:

Fortunately there's not much more to be displayed beyond Desktop,System...Fun+BB, but indeed there are some additional categories in some of the repos:

# awk -F'|' '{print $5}' /root/.packages/Packages-* | grep -vE 'Desktop|System|Setup|Utility|Filesystem|Graphic|Document|Business|Personal|Network|Internet|Multimedia|Fun|BuildingBlock' | sort -u

Archiving
BuildngBlock
Calculate
Develop
Development
Multmedia
Pesonal
# 

However half of them are just malformed entries - BuildngBlock, Multmedia & Pesonal, lol.
___________

@Bigpup:

I, too, think that "Any type" should be set by default.

As for the max. 5 repos limit, I have enabled all of them and it looks ok, no impact on speed & responsiveness, works just fine...
I agree that probably the only limitation was the design of ui_Classic, but I've redesigned it - maybe it's not so pretty, but TBH it never was...
Besides, ui_Ziggy is default.





But I suppose that the decision which repos are enabled/visible OOTB is up to developers at the stage of building a distro.

Ok, if anyone wanna test/play with it, I have attached modified files from /usr/local/petget/.
Note, that they're compatible only with woof-CE based Puppies.

PPM_test_1.tbz2

Greetings!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

mavrothal
I believe the "wisdom" behind the absence of building blocks and the default to GUI execs is that PPM is aimed at the "less competent"  user.
Presenting a gazillion of cryptic filenames in building block and 10 versions of the same package after enabling all the repos, can be confusing and can even mess up your system if you do not know what you are doing.
Power/seasoned users can find their way arround even without these "enhancements". I'm not sure if the opposite is also true for the novices.
Ideally (and very puppy-like) this "enhancements" could be available in an optional "advanced" mode ( that will be coming with the necessary explanations and warnings)  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

JakeSFR
Well, I agree about DEV/DOC/NLS (unnecessary clutter OOTB), but the possibility to enable all repos at once is just a time saver and faciliation.

Of course all of them shouldn't be enabled by default!
In example of Slacko:

- puppy-slacko14-official
- slackware-14.0-official
- slackware-14.0-patches (not sure, maybe not?)
- slackware-14.0-salix
- slackware-14.0-slacky
- puppy-common-official
- puppy-noarch-official

is a reasonable choice, IMHO.

As for BB - yeah, all those libs, kernel modules and other core stuff could be ignored, if only the "valuable" rest (mentioned vim etc.) was in appropriate categories...but OTOH other distros (also targetted for beginners) don't seem to hide anything, eg. PCLOS:



Naturally PPM is not Synaptic; I'm only making a point.
Anyway, after selecting "BuildingBlock" category, there could be a pop-up window with a warning that "You're entering advanced zone!" or sth like that. ;)

Greetings!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

mavrothal
This post was updated on .
PPM is not synaptics and Ubuntu and friends have synaptics as secondary app installer.
Regarding more repos, I see little value and a lot of trouble in activating pet_packages-2, 3, drake or even lucid.
There are indeed cases that the limit of 5 is not enough to accommodate all the _relevant_ repos but I guess this should be up to the puppy builder to decide.
Anyway, feel free to commit as you see fit.
Our of the nice points of git is that you can always reverse commit if people start complaining ;)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

bigpup
In reply to this post by JakeSFR
quote:
There are indeed cases that the limit of 5 is not enough to accommodate all the _relevant_ repos but I guess this should be up to the puppy builder to decide.

That is exactly the problem. With a max limit of 5 repos showing at one time, the developer is limited on what he wants visible.

01micko had this issue with Slacko.
PPM had 6 repos selected, by default, to be listed, but only 5 were showing.
puppy- noarch  was the one that did not show up.

Try looking for a cursor theme without puppy-noarch repo listed.
Pcur Cursor Selector tells you to download the cursor theme from puppy-noarch so you can use the program.

cursor_themes-1-1 is the standard theme package puppy has been using for a long time.

No one pre-installs it in their Puppy version, because Pcur Cursor Selector tells you where to find it, when you first run the program.

Let the puppy version developer decide what repos are listed, by default, and remove this limit of a max of 5 at one time can be listed in PPM.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

mavrothal
This post was updated on .
But for a developer is trivial to adjust the number of repos allowed if (s)he thinks that is important.
All it needs is to change "5" in line 124 of /usr/local/petget/configure.sh and line 187 in pkg_chooser.sh

The point is if the user should be presented with all the puppy packages ever build from 1994 onwards.
And if you do not want to go that far imagine is the (incompatible) "slacko" repo is activated in slacko14 builds or even worse the "slacko64"!
I think is not a good idea.
Unless there is an additional rigid mechanism to exclude incompatible repos.

But as I said many people can commit in woof-CE ;)
 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

JakeSFR
The point is if the user should be presented with all the puppy packages ever build from 1994 onwards.
Of course not, that was never my intention...
My mod won't make all (available) repos presented OOTB, it only gives such possibility for a user/developer.

And if you do not want to go that far imagine is the (incompatible) "slacko" repo is activated in slacko14 builds or even worse the "slacko64"!
I think is not a good idea.
Hmm, users can do it regardless of how many repos can be displayed at once - it's enough for them to untick one of already enabled repos and tick another in configuration window.
So I don't really understand what's the difference (in the matter of compatibility) if there can be 3, 5, 11 or ∞ repos to choose from, displayed in the main window?
The only difference is ease of use and flexibility, I believe.
And the real question is: should those "dangerous", incompatible repos be there at all? (btw, "slacko64" repo is not included in 32bit Slackos)

Anyway, feel free to commit as you see fit.
Our of the nice points of git is that you can always reverse commit if people start complaining ;)
Thanks, I will. :)
But first I'd like to have more opinions and rethink some details, eg.: perhaps the cryptic "BuildingBlock" category should be displayed as "Other" or "Uncategorized"?
Would be more descriptive for uninitiated. ;)

Greetings!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

bigpup
In reply to this post by JakeSFR
Now the question becomes,
Does the Puppy version developer, need to really look at, what is listed for available repos in PPM?
Is there a good chance he/she is providing options that just do not work?

Example:
Look at the possible repos in the Slacko 5.7 PPM.
Puppy 2 official
Puppy 3 official
Puppy 4 official
etc...

I have not tried, but a good guess is anything in Puppy 2 or 3 official would probably not work. At best would have some kind of problem.
Even Puppy 4 or 5 official would probably have some issues.

So, is this something the developers of Puppy need to take a good hard look at, before they release a Puppy version?
What they are really offering, in the PPM, in their version of Puppy.

 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

bigpup
In reply to this post by JakeSFR
quote:
But first I'd like to have more opinions and rethink some details, eg.: perhaps the cryptic "BuildingBlock" category should be displayed as "Other" or "Uncategorized"?
Would be more descriptive for uninitiated. ;)

Are any of these files ones a normal user would want to install?
Are any of them dependencies for other programs?
Would installing any of them cause something to not work or would they just add additional files?

If you are going to put them in a separate category, I do not think  "Uncategorized" would be a good name.
That name makes me think there is something in there that just does not fit in any other category.

A name telling me the stuff in this category are things I do not normally need, but may want to have access to at some time.
"BuildingBlocks" says that to me.
Indicates to me normal programs are not in that category.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

mavrothal
In reply to this post by bigpup
> So, is this something the developers of Puppy need to take a good hard look at, before they release a Puppy version?
> What they are really offering, in the PPM, in their version of Puppy.

Well, they actually do. But what is really needed is for the repos to cleanup and rationalize.
If this happen then any puplet should only need -noarch, -pupplet-specific, and maybe -common (depending what is left in "common"), and of course the binary compatible repos (if is not a T2 build).
However, cleaning up the repos may generate problems for older puppies so is a bit of a problem.
New repos could be generated but this may be an unnecessary duplication.
I'm not sure if ibiblio supports symlinks but if it does a new "common-CE" repo where only binaries with no dependencies will be included and a noarch-CE where all the text-executables will be gathered, maybe the way to go.
It is a lot of work specially if any kind of QA is involved. With 3-4 active developers and at least 7 active flavors of puppy out there (2, 4, lucid, precise, slacko, slacko14, T2) is a nightmare. Add debian, drake and mageia to get the full repo situation. The entire linux (caco)polyphony in one distro...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

JakeSFR
In reply to this post by bigpup
I have not tried, but a good guess is anything in Puppy 2 or 3 official would probably not work. At best would have some kind of problem.
Even Puppy 4 or 5 official would probably have some issues.
I guess some small apps should work without problems, even from puppy-2 repo, but some (majority?) surely not.

Are any of these files ones a normal user would want to install?
Well, I suppose so - among "boring" (for average user) things there are also fonts, text editors [vim], system monitors [gkrellm], security/encryption [gnupg, ccrypt], math [gnuplot], graphics [imagemagick, hugin], compression [lrzip], geography (?) [marble], icon themes [tango, faenza], emulators [arnold, dosbox], video [cinerella], even games [2H4U] and so on. and so on...

Are any of them dependencies for other programs?
Would installing any of them cause something to not work or would they just add additional files?
3x Yes. But if users don't know what given packages are for, they shouldn't install them at random, in the first place.
Besides, each pkg has a description.

If you are going to put them in a separate category, I do not think  "Uncategorized" would be a good name.
That name makes me think there is something in there that just does not fit in any other category.
Technically, I'm not "going to put them in a separate category", they're already there - I just want to make that category accessible.

A name telling me the stuff in this category are things I do not normally need, but may want to have access to at some time.
"BuildingBlocks" says that to me.
Indicates to me normal programs are not in that category.
So, you're saying it's better to stick with that cryptic name in order to keep noobies out of there, lol. :D

Thanks for the comments &
Greetings!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

JakeSFR
Hmm, part of the problem with "good" apps inhabiting BB category is /usr/local/petget/categories.dat file, which defines *what* goes *where* and, unfortunately,  omits lots of useful apps.
So, adding missing pieces there would do the job, but only in case of slackware*/ubuntu*/debian* etc. repos.
In 'Packages-puppy-*' files (from http://distro.ibiblio.org/puppylinux/) all categories are already hardcoded. :/
Too much hassle, I'm afraid...

Anyway, since I still think that it's a good thing to have access to BB category, but OTOH it can be dangerous for novices, I decided to resolve this issue simply by adding "Enable BuildingBlock category (for advanced users only!)" checkbox at the left bottom corner of PPM's configuration window (false by default, of course).
I think it's a fair compromise.

If no objections, I'll commit the changes in a few days.

Greetings!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

iguleder
Things like this crappy static database of categories are simply disgusting. Personally, I do not like Barry's coding style (for many reasons - this ain't personal, no offense) - legacy code should be deleted instead of getting commented-out and efficiency should be a priority, always.

I think PPM is rotten. I've got many, fast awk-based package list converters for Debian, Slackware, RPM-based distros and much more. What do you think - should I take the time and try to build a new backend for PPM?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

JakeSFR
If you feel like, why not? :)
Btw, do these converters can handle assigning to puppy-specific categories?
I also don't like this 'categories.dat' mechanism, but as I "understand" (perhaps wrongly - package management is not my domain), it was the only way to categorize pkgs, having eg.:
http://slackware.cs.utah.edu/pub/slackware/slackware-14.0/PACKAGES.TXT
as input data...

Greetings!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

mavrothal
In reply to this post by iguleder
> I think PPM is rotten. I've got many, fast awk-based package list converters for Debian, Slackware, RPM-based distros and much more. What do you think - should I take the time and try to build a new backend for PPM?

One of the problems with PPM is that shares code/is used in puppy building.
A complete revamp of PPM should consider this aspect too.
Regarding puppy menu categories, I really see no reason not to be GNOME-compliant other than historical reasons but unfortunately they are there and must be considered for compatibility.

Quite frankly I think is time for a woof3 branch where the entire building process will be reconsidered with as few as possible strings attached other than the multi-arch/multi-distro and main/devx SFS building and a PPM/build system to support these.
However, interested parties may want to discuss the technical details of this new build infrastructure first. Maybe in a dedicated thread here or even in private (if they choose to further minimize "noise").
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PPM is too secretive

jamesbond3142
On Fri, 25 Apr 2014 04:27:53 -0700 (PDT)
"mavrothal [via woof-CE]" <[hidden email]> wrote:

>
>
> > I think PPM is rotten. I've got many, fast awk-based package list
> converters for Debian, Slackware, RPM-based distros and much more. What do
> you think - should I take the time and try to build a new backend for PPM?
>

One thing that immediately struck me is - why do we need to use converters in the first place?
Why don't we use upstream distro's native package manager?
This way, no need for conversion and as soon as upstream packages are updated; users will get notified too.

The only downside I can see is that we have to package Puppy-specific packages multiple times (one for DEB, one for RPM) but surely this can be scripted.

T2-builds of Puppy doesn't have native package manager, but:
a) does anybody still build T2-based puppy?
b) if we do build T2-puppy (or another source-based Puppy), we can always choose and pick one from the more popular package managers - this can be Dima's package manager, and/or other popular package manager from other distros.

> One of the problems with PPM is that shares code/is used in puppy building.
> A complete revamp of PPM should consider this aspect too.

True. But this should not be. Why should it?
The only that should matter is that when packages are installed for puppy building purposes, they should be tracked so that people knows what they are (and can then choose to "uninstall" it).

The only reason why PPM comes into the picture is because puppy build and PPM uses the same script - install_pkg.sh IIRC - to install packages. When we use a different package manager, install_pkg.sh will be replaced by native's version of package installer (dpkg-deb, rpm, etc).

> Regarding puppy menu categories, I really see no reason not to be
> GNOME-compliant other than historical reasons but unfortunately they are
> there and must be considered for compatibility.

If we want to go that way, this can be worked on by having a script to scan through all .desktop files and update the Categories= line containing update categorisation to a new one - so old packages will automatically have their menus listed in the correct categorisation. Or we can do it the other way around, foreign packages got their categorisation changed to comply with Puppy's :)

>
> Quite frankly I think is time for a woof3 branch where the entire building
> process will be reconsidered with as few as possible strings attached other
> than the multi-arch/multi-distro building and a PPM/build system to support
> multi-arch/multi-distro.

Yup, the stable/next flavours (or release/experimental, if you wish :p).

12
Loading...