It creates .pget files, which are simply pupget format .tar.gz files renamed to end in .pget. The idea is that the much-liked "click to install" capability of .pup files can now (soon!) be realized for .pget files too, by writing a short script for Rox to deal with .pget files by executing /usr/sbin/pupget so as to install them.

It is still in its infancy. Developers (people who are comfortable compiling source tarballs by hand): please do try it and report successes, failures, suggestions for improvement, etc. End users who are not used to compiling things: this is probably not for you.

Known missing functionality:

Does not handle packaging *.xpm files into the root of the tarball at all.

Does not handle multiple keywords in the keyword file.

Does not allow packager to specify a keyword (just creates one based on the source filename).

Jonathan

pupgetmaker.sh.gz

Description

pupgetmaker.sh is a shell script to compile source tarballs into pupget packages with the new .pget extension.

* Does not handle packaging *.xpm files into the root of the tarball at all.
* Does not handle multiple keywords in the keyword file.
* Does not allow packager to specify a keyword (just creates one based on the source filename).

The xpm files are important, and so is the chopice of keyword.

Quote:

It creates .pget files, which are simply pupget format .tar.gz files renamed to end in .pget. The idea is that the much-liked "click to install" capability of .pup files can now (soon!)

I know... these capabilities will be added in a day or two, God willing. I don't see them as major obstacles. For now, try building non-GUI packages -- then the lack of GUI icons and menu entries in the resulting package is not such an issue

jmarsden wrote:

It creates .pget files, which are simply pupget format .tar.gz files renamed to end in .pget. The idea is that the much-liked "click to install" capability of .pup files can now (soon!)

which strongly suggest to me that adding the click-to-install capability to Rox will not need any change to /usr/sbin/pupget at all.
If Rox can execute

Code:

/usr/sbin/pupget +$FILE

when a .pget is clicked on, pupget should install it. I may even have this working later tonight, stay tuned!

I'm rather hoping I don't have to hack on /usr/sbin/pupget except for my own internal testing. I'd rather rewrite it than try to support a hacked version of it. A 900 line shell script that isn't extremely well structured and commented just isn't going to be very supportable or extendable, in my view. And (in case you haven't read it) /usr/sbin/pupget doesn't really qualify for those descriptions. Someone else decribed it as "hairy"

Rox should now recognize the .pet file extension
you can either right click a .pet file to set it's Run Action ... or put a file called something like application_pet in /root/Choices/MIME-types/ ... application_pet might have something like

#!/bin/sh
exec pupget +"$1"

in it ... or it could run a wrapper script, maybe to make a symlink to the file that would have a name without the .pet extension, if pupget doesn't like the extension

in /root/.local/share/mime/packages/rox.xml
then you would type:
update-mime-database /root/.local/share/mime
to update the shared-mime-database
i guess you would have to have Rox reread it's config files
then you can setup the Run Action by right clicking a .pet file ... the Run Action file will be something like
/root/.config/rox.sourceforge.net/MIME-types/application_pet

please do try it and report successes, failures, suggestions for improvement, etc.

However this is a suggestion for pupgetmaker that has to be taken into consideration.

Many pacakges compile and install .xpm to /usr/share/pixmaps which is a link to /usr/local/lib/X11/pixmaps. Prior experience has shown that overwriting a if a link in the union gets overwritten it breaks the union. So if some pacakges is going to overwrite a linked folder it can use the readlink command to install the files in their correct location.

However this is a suggestion for pupgetmaker that has to be taken into consideration.

Many pacakges compile and install .xpm to /usr/share/pixmaps which is a link to /usr/local/lib/X11/pixmaps. Prior experience has shown that overwriting a if a link in the union gets overwritten it breaks the union. So if some pacakges is going to overwrite a linked folder it can use the readlink command to install the files in their correct location.

Please could you provide us with two example pupget packages that demo this -- one that does it the wrong way and one that does it correctly? And some clear instructions for making the "bad pupget" break unionfs-related things? The example pupget's don't need to do anything of value (display "hello world", maybe?). I'm not sure precisely how to cause the problem you are referring to. Does the package have to try to "install" the actual directory /usr/share/pixmaps itself to cause breakage, or just to install a file inside that directory?

Regarding the .pet/.pget extension, I don't care all that much what extension it has. I'm very surprised that we would be expecting a lot of Windows users to be downloading these packages and "getting confused", though.

(a) Surely most users will download and use them with (an enhanced version of) pupget, or by using another tool from within Puppy itself?

(b) I can download any binary file with any reasonable NTFS-OK filename on my one Windows PC here just fine... why would Windows users care about how long the .extension is? I just uploaded a file named filename.dachshund to a FTP server and then downloaded it using IE in Windows XP Home. Worked fine. Same when using FileZilla to download it. I suspect it would work just as fine in Win95 with a FAT32 filesystem, even! (I admit, I didn't add a new application/x-dachshund MIME type associated with .dachshund files on the server first, sot it wasn't a really thorough test!).

What am I missing? Is someone really going to create a Win32 native app that creates or unpacks pupget packages? Why? Anyone who (for some reason) chooses to play with them under Windows would IMO be wise to use Cygwin or something similar anyway, so there is at least some chance that shell scripts such as pinstall.sh within them are somewhat useful.

Further, I don't think we can legitimately just generate a new MIME type of application/pet (or application/pupget or whatever). That's not permitted by RFC 4288 -- at least as I read it. I think we can reasonably use application/x-pet or similar, if we need a new MIME type to experiment with. Though officially, even new application/x-* naming of experimental MIME types is now "discouraged", and has been for 9+ years.

I note that even older well known package formats such as .deb and .rpm use application/x- types. Today. Even in Puppy itself! Did someone in the Puppy community really create a formal standard definining the .pup package format, publish it asn an RFC, etc etc., submit the relevant application to IANA per RFC4288 (or RFC2048 which preceeded it), and get application/pup registered? I don't see it listed as such. Or (more likely, IMO) did someone play with new MIME types in Puppy (or Rox), without doing their homework on how to obtain a new one by reading the relevant RFCs first?

I suggest that this (almost certainly accidental) breach of Internet community standards be considered a bug, and fixed in Puppy 1.0.8 and 2.x, or perhaps even sooner, in a "service pack" to 1.0.7 ?

the file /usr/local/share/Choices/MIME-info/Standard is used only by Rox 1.2 ... it is used to determine whether rox will recognize a particular file extension (and thus allow you to set a Run Action for that file type) ... or not

the format is similar to the way Gnome libraries used to handle mime types, but it does not have all the features ... basically, the mime type is in the list, or it isn't

as far as i know, the file is only used by Rox, and is not used by Gnome programs or libraries, or any other program or library ... it is only used by Rox to decide whether a particular extension should have a Run Action or not

and of course, it has absolutely nothing whatever to do with the internet

Quote:

new MIME types in Puppy (or Rox)

yes, this is all the pup line in the mime file does ... it tells Rox to have a Run Action for files with a .pup extension

Quote:

be considered a bug

it is hardly a bug ... simply a design choice
you can put whatever you like in the Rox mime config file, as long as you stick to the format

originally, i was going put an application/x-pup line in Standard, but i decided that

1) since a .pup file is really a zip file anyway, i would simply use the same format that was used for zip files

application/zip
ext: zip

application/pup
ext: pup

2) application/pup is (slightly) simpler than application/x-pup

either will work (for that matter, i think application/woofwoof-pup will also work) ... i don't care if anyone wants to change it