The time now is Sat 25 May 2013, 05:20
All times are UTC - 4 |
| Author |
Message |
jmarsden

Joined: 31 Dec 2005 Posts: 263 Location: California, USA
|
Posted: Mon 16 Jan 2006, 01:49 Post subject:
pupgetmaker.sh v1.1 -- compiles source tarballs into pupgets |
|
Here is pupgetmaker.sh, a very similar script to dpupmaker.sh.
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
 |
| Description |
pupgetmaker.sh is a shell script to compile source tarballs into pupget packages with the new .pget extension.
|

Download |
| Filename |
pupgetmaker.sh.gz |
| Filesize |
2.22 KB |
| Downloaded |
509 Time(s) |
|
|
Back to top
|
|
 |
Nathan F

Joined: 08 Jun 2005 Posts: 1641 Location: Wadsworth, OH (occasionally home)
|
Posted: Mon 16 Jan 2006, 01:55 Post subject:
|
|
I'll giveit a whirl in a day or two. In the meantime:
| Quote: | 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). |
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!) |
Is this a sign that you're hacking at Pupget also?
Nathan
|
|
Back to top
|
|
 |
jmarsden

Joined: 31 Dec 2005 Posts: 263 Location: California, USA
|
Posted: Mon 16 Jan 2006, 02:19 Post subject:
|
|
| Nathan F wrote: | | The xpm files are important, and so is the chopice of keyword. | 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!) |
| Nathan F wrote: | | Is this a sign that you're hacking at Pupget also? | Not yet. I'm reading its code. It does things like | Code: | if [ "$1" ];then
COMMANDPKG="$1"
#want pupget script to be noninteractive.
| 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"
Jonathan
|
|
Back to top
|
|
 |
unlogged Nathan
Guest
|
Posted: Mon 16 Jan 2006, 02:25 Post subject:
|
|
Yes, I've read it and even hacked it a little. I've also seen worse.
Nathan
|
|
Back to top
|
|
 |
GuestToo
Puppy Master
Joined: 04 May 2005 Posts: 4078
|
Posted: Mon 16 Jan 2006, 02:53 Post subject:
|
|
| Quote: | | adding the click-to-install capability to Rox |
it's really easy, if you change the file extension
i like .pet myself
to setup a mime-type in Rox 1.2:
put a file in /root/Choices/MIME-info/ ... call it pupget, if you like ... add the mime info to the file, something like:
| Code: | #
application/pet
ext: pet |
in Rox options, Types tab, click the Reread Files button (or restart Rox or restart X or reboot)
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
Rox 2.4 is a little different ... you would put something like
<mime-type type="application/pet">
<glob pattern="*.pet"/>
</mime-type>
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
|
|
Back to top
|
|
 |
GuestToo
Puppy Master
Joined: 04 May 2005 Posts: 4078
|
Posted: Mon 16 Jan 2006, 02:56 Post subject:
|
|
| Quote: | | put a file in /root/Choices/MIME-info/ |
or you can just edit
/usr/local/share/Choices/MIME-info/Standard
|
|
Back to top
|
|
 |
MU

Joined: 24 Aug 2005 Posts: 13642 Location: Karlsruhe, Germany
|
Posted: Mon 16 Jan 2006, 05:49 Post subject:
|
|
I too think we should use .pet , so windows-users don't get confused.
.pget was just a "codename" to describe the functionality in the meeting.
Greets, Mark
|
|
Back to top
|
|
 |
Lobster
Official Crustacean

Joined: 04 May 2005 Posts: 15109 Location: Paradox Realm
|
Posted: Mon 16 Jan 2006, 06:23 Post subject:
Package Extension Technology aka .pet |
|
I agree
.pet = Package /Puppy Extension /Extras Technology ?
_________________ Puppy WIKI
|
|
Back to top
|
|
 |
MU

Joined: 24 Aug 2005 Posts: 13642 Location: Karlsruhe, Germany
|
Posted: Mon 16 Jan 2006, 06:33 Post subject:
|
|
.pet = windows-conform abreviation of .pget
pet = house-animal (dog)
pet PuppyExTension
yes. so there a several ways you could associate it
|
|
Back to top
|
|
 |
Guest
Guest
|
Posted: Mon 16 Jan 2006, 06:55 Post subject:
|
|
or this will give .pet and .pget the same Run Action
| Code: | application/pet
ext: pet pget |
that is, clicking a .pet file will do the same thing as clicking a .pget file
Rox will get mime info from any and all files that are in $HOME/Choices/MIME-info/ and /usr/local/share/Choices/MIME-info/
- G2
|
|
Back to top
|
|
 |
Guest
Guest
|
Posted: Mon 16 Jan 2006, 07:05 Post subject:
|
|
and you can have an icon for .pet files
/root/Choices/MIME-icons/application_pet.xpm
/root/.config/rox.sourceforge.net/MIME-icons/application_pet.png
or the icons can go in /usr
-G2
|
|
Back to top
|
|
 |
bombayrockers

Joined: 24 Sep 2005 Posts: 421 Location: Mumbai, India
|
Posted: Mon 16 Jan 2006, 07:09 Post subject:
|
|
I have not tested pupgetmaker.sh
| Quote: | | 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.
|
|
Back to top
|
|
 |
jmarsden

Joined: 31 Dec 2005 Posts: 263 Location: California, USA
|
Posted: Thu 19 Jan 2006, 00:42 Post subject:
|
|
| bombayrockers wrote: | 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?
Thanks,
Jonathan
|
|
Back to top
|
|
 |
jmarsden

Joined: 31 Dec 2005 Posts: 263 Location: California, USA
|
Posted: Thu 19 Jan 2006, 04:10 Post subject:
|
|
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 ?
Jonathan
|
|
Back to top
|
|
 |
GuestToo
Puppy Master
Joined: 04 May 2005 Posts: 4078
|
Posted: Thu 19 Jan 2006, 21:39 Post subject:
|
|
| Quote: | | breach of Internet community standards |
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
|
|
Back to top
|
|
 |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|