If anyone is interested, post here so that we don't have two people doing the same thing -- well, I am assuming that more than one person will be interested in doing this! Or even one for that matter.

I was thinking that this is something that someone can do who wants to contribute to Puppy development, but is not into shell/bacon/c or whatever programming, or anything system-level._________________http://bkhome.org/news/

all of this _could_ be accomplished by downloading the package, extracting the .desktop file and parsing it ... if it doesn't have a desktop file it would be pretty safe to assume building block. I wrote a similar script for pet packages that scottman used in akita last year.

0ad is 1st in HASdesktopFILE and is 1st in PKGS_HOMEPAGES
.
.
bouncy is 175th in HASdesktopFILE and is 843rd in PKGS_HOMEPAGES
.
and so on (wait some hours)
packages which have .desktop file: less than 20%

I almost forgot that debian/ubuntu keep a list of files in each package, which could help avoid unnecessary downloads.

@L18L - most of the code for parsing the desktop files is already written as part of jwm_menu_create, just have to remove the jwm xml bits and unneeded lines, but I don't have a good feel of what barry is checking against regarding package names from distro to distro. In actuality it would be easy enough to create a whole database template that only requires filling in the full package name and size for each distro and appending any that are missing from the template

@aragon, once the database is created, it should be applicable to most distros

@barry, I'm not sure how much the different distros vary in their package names and how you account for the different naming such as abiword-x.x.txz vs abiword-bin-x.x.deb, etc... if they all somehow listed the executable, that would be the easiest since I could just use the Exec= and Categories= lines from the desktop files, ... otherwise it would require some manipulation of the package name (I am assuming this is coded somewhere already)_________________Web Programming - Pet Packaging 100 & 101

... debian/ubuntu keep a list of files in each package, which could help avoid unnecessary downloads.

@L18L - most of the code for parsing the desktop files is already written as part of jwm_menu_create, just have to remove the jwm xml bits and unneeded lines, but I don't have a good feel of what barry is checking against regarding package names from distro to distro. In actuality it would be easy enough to create a whole database template that only requires filling in the full package name and size for each distro and appending any that are missing from the template

I have grepped that filelist, results in 2080 packages (only ), see above.

Now I do not know how to "look" inside a .deb (extract the .desktop file) without installing

all of this _could_ be accomplished by downloading the package, extracting the .desktop file and parsing it ... if it doesn't have a desktop file it would be pretty safe to assume building block. I wrote a similar script for pet packages that scottman used in akita last year.

technosaurus,
This already happens on a per-package basis in /usr/local/petget/installpkg.sh when a package is installed. The script tries to make sure the .desktop file "Categories" field is appropriate for the Puppy menu structure.
Doesn't always get it right though, which is why a 'categories.dat' would be nice to check against -- perhaps that file could be initially created with a script, then each entry manually checked for correctness -- but then it might be better to do it all manually, which was my original thinking, and why I suggested a non-developer would like this.

Quote:

2080 packages have desktop files

L18L,
That's great, then probably a huge number of these are very exotic and could be ignored -- not put into categories.dat, meaning that the automatic category determination performed in debdb2pupdb will be deemed good enough.

Quote:

If a puppy is based on other distros packages it needs to reflect the distros menu-categories or it needs a script that converts the offending categories to puppy-categories on installation.

aragon,
Puppy's menu structure is unique. .desktop files are modified at installation, as mentioned above. However, the automatic mechanism doesn't always get it right.
Also, the PPM needs to know the categories of all packages prior to installation, as they are displayed in categories, and icon thumbnails are assigned on a per-sub-category basis.
The categories that the PPM displays must fit the Puppy menu structure.
The categories are in every package database entry -- which is done by the -to-pup-db converters such as 'debdb2pupdb'._________________http://bkhome.org/news/

@aragon, once the database is created, it should be applicable to most distros

Yes. Well, applicable to all distros supported by Woof.

technosaurus wrote:

@barry, I'm not sure how much the different distros vary in their package names and how you account for the different naming such as abiword-x.x.txz vs abiword-bin-x.x.deb, etc... if they all somehow listed the executable, that would be the easiest since I could just use the Exec= and Categories= lines from the desktop files, ... otherwise it would require some manipulation of the package name (I am assuming this is coded somewhere already)

PKGS_HOMEPAGES has generic names for packages. Ubuntu and Debian do use some odd names, and also split original packages up into many smaller ones -- however I have got around this problem as the Ubuntu/Debian database does also contain generic names.

Ubuntu/Debian keep packages in their online repos in folders named by the generic name, that's how I am able to obtain the generic name and check against lists such as categories.dat and PKGS_HOMEPAGES.

Though, the folder names in the Ubuntu/Debian online repos do not always correspond to the original package name, so it is not a perfect method.

Most other distros keep the original generic naming of packages, Slackware for example, so no problem.

Mageia is one example that splits up packages a lot and renames them. I don't yet know if the generic names can be determined for Mageia, probably some way to do it._________________http://bkhome.org/news/

Now I do not know how to "look" inside a .deb (extract the .desktop file) without installing

undeb <pkg>,... but I forgot to send my undeb patch in to busybox for xz and I seem to have lost it, so you will need the full (and recent) package since they seem to be using xz in at least some if not all deb packages now._________________Web Programming - Pet Packaging 100 & 101

Now I do not know how to "look" inside a .deb (extract the .desktop file) without installing

undeb <pkg>,... but I forgot to send my undeb patch in to busybox for xz and I seem to have lost it, so you will need the full (and recent) package since they seem to be using xz in at least some if not all deb packages now.

One more point about the menu-structure: it would be nice if the menu-points help and submenu shutdown would be implemented as desktop-files and desktop-catetegory. This would ease internationalization and the need to have static parts in templates would be superflous.

One more point about the menu-structure: it would be nice if the menu-points help and submenu shutdown would be implemented as desktop-files and desktop-catetegory. This would ease internationalization and the need to have static parts in templates would be superflous.

Aragon

It may be too big for puppy but it isn't _that_ much to copy all of the desktop files to a separate directory like /usr/share/applications.uninstalled
and replace Exec=app with Exec=installer package_name (where "installer" is a wrapper around petget and removes the .uninstalled/*.desktop file after install) such that the whole thing can be parsed into an install menu ... we could also go through them and check the Icon= field to see if the icon exists and if not, make a symlink for it based on the Categories= field (jwm_tools already has a similar installer menu to this)_________________Web Programming - Pet Packaging 100 & 101

@L18L does it look like we need to do something like:
echo Package=$PACKAGENAME >> package/.../*.desktop
so we have a basis for determining the package name, or are most fairly straight forward

I am stuck in windows mode until I finish my programming languages project, so I can only give guidance right now, but if you open up jwm_menu_create (from jwm_tools) all of the language is there to generate all subcategories, all that needs to be done is:
set the subcategories variable to true (i forget the exact var name)
change the directory path from /usr/share/applications to the appropriate dir. remove the unneeded jwm markup
change the output to just give the format that Barry needs, which is ???
(p.s. my sub-category names may slightly differ but that is easily fixed by humans pretty quickly)
I assume that output could be:
category|subcategory|packagea packageb

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum