PuppyFiles.us - Updates & Discussion
-
Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
Babbs - the installer
Puppy2 Alpha will give us some more insights
- remember we may be calling capabilities from other packages. For now you seem to be heading in the right direction (if I may so say).
.pet does not exist
but we have programs available in:
pget
unleashed (install as an alien package with pupget)
.pup
and sfs format
as well as some programs are self installers and should also be considered
For example I was amazed to know that Open Office could just be downloaded and installed
So for major packages that might be considered . . .
I was looking at the DSL installer
MU's .pup installer and Barry's pupget and GuestToos Wiki pages are much better - more info, clearer
Much to my surprise our developers prefer
text to XML - so aim for that - tab delimited should be OK
And yes we should discuss this at the Foundation meeting - you can put it on the agenda - only 3 things on it at the moment
Lobster,
Would you mind adding it to the agenda for me? I'd rather defer the wording to someone else.
As to the direction I'm heading, I am only preparing an infrastructure that Puppy can leverage. Although the devil is in the details, I'm not concerning myself with those details right now. Supporting 1, 2, 3, 5, or 10 different file types is not important to me, but it will be important to whoever does the scripts to read the repository.
I did notice the text vs xml discussion, but I think that revolved around hand-jamming the data into the xml format and the resulting file size. To me the "listings" file format is unimportant since I can format it either way, but the format will be important to whoever writes the script to access it.
Although there is a lot of effort on my part to get it configured right, my goal is to make the repository concept a reality, and to do so in a manor that is easy to maintain by the developers. Part of my plans include single file uploads plus the ability of batch uploading to accomidate multiple files. Again, I am trying to make this as simple as possible for the developers to maintain and keep current.
I realize that didn't mention it previously, but another area that needs to have serious consideration is the idea of categories. The number doesn't matter to me, but there should be a concensus as to what they will be to begin with.
Access to the repository will be in tiers:
- Guest (and automated access) - Access to download the packages/files without logging in
- Registered - Guest access plus the ability to comment on the packages
- Developers - Registered access plus the ability to upload packages into "testing"
- Admin - Developer access plus the ability to approve uploaded packages into "stable" and the ability to change registrations from "Registered" to "Developer" (and back if needed)
- Super Admin - Limited to just a few people
The package information will include "tested on Puppy version ___" information, as well as multiple revisions. So if a package that works with Puppy 1.0.7 needs to be changed to work with Puppy 2.0.0, then there would be both versions of the packages stored. I know that placing constraints on the developers is not a real good idea, but adding version numbers to the packages makes good sense (eg. PackageName_0.0.3.pet) so that we don't have to rely on file dates to know which version is newer. Other input fields will include Package Name (this usually different that the file name) and a short description. Optional fields will include a long description, installation instructions, and developer comments. As indicated above, "Registered" members of the site will be able to post comments about the packages, and (not mentioned above) they will be able to rate the packages.
I am also going to provide package upload notification via email and RSS for those who desire to be kept informed by these methods.
If this package upload system is granted access, it will have the ability to update multiple mirror sites (single point of upload, multiple points for download). I also intend the web interface be able to offer multiple mirror choices so the user can download from the site that is closest to them.
My goal is to have the basic framework in place for review for this weekend's meeting.
Time to go catch 30 minutes sleep before getting up for work...
More later,
Babbs
Would you mind adding it to the agenda for me? I'd rather defer the wording to someone else.
As to the direction I'm heading, I am only preparing an infrastructure that Puppy can leverage. Although the devil is in the details, I'm not concerning myself with those details right now. Supporting 1, 2, 3, 5, or 10 different file types is not important to me, but it will be important to whoever does the scripts to read the repository.
I did notice the text vs xml discussion, but I think that revolved around hand-jamming the data into the xml format and the resulting file size. To me the "listings" file format is unimportant since I can format it either way, but the format will be important to whoever writes the script to access it.
Although there is a lot of effort on my part to get it configured right, my goal is to make the repository concept a reality, and to do so in a manor that is easy to maintain by the developers. Part of my plans include single file uploads plus the ability of batch uploading to accomidate multiple files. Again, I am trying to make this as simple as possible for the developers to maintain and keep current.
I realize that didn't mention it previously, but another area that needs to have serious consideration is the idea of categories. The number doesn't matter to me, but there should be a concensus as to what they will be to begin with.
Access to the repository will be in tiers:
- Guest (and automated access) - Access to download the packages/files without logging in
- Registered - Guest access plus the ability to comment on the packages
- Developers - Registered access plus the ability to upload packages into "testing"
- Admin - Developer access plus the ability to approve uploaded packages into "stable" and the ability to change registrations from "Registered" to "Developer" (and back if needed)
- Super Admin - Limited to just a few people
The package information will include "tested on Puppy version ___" information, as well as multiple revisions. So if a package that works with Puppy 1.0.7 needs to be changed to work with Puppy 2.0.0, then there would be both versions of the packages stored. I know that placing constraints on the developers is not a real good idea, but adding version numbers to the packages makes good sense (eg. PackageName_0.0.3.pet) so that we don't have to rely on file dates to know which version is newer. Other input fields will include Package Name (this usually different that the file name) and a short description. Optional fields will include a long description, installation instructions, and developer comments. As indicated above, "Registered" members of the site will be able to post comments about the packages, and (not mentioned above) they will be able to rate the packages.
I am also going to provide package upload notification via email and RSS for those who desire to be kept informed by these methods.
If this package upload system is granted access, it will have the ability to update multiple mirror sites (single point of upload, multiple points for download). I also intend the web interface be able to offer multiple mirror choices so the user can download from the site that is closest to them.
My goal is to have the basic framework in place for review for this weekend's meeting.
Time to go catch 30 minutes sleep before getting up for work...
More later,
Babbs
)-
Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
There is not much there but I have added itbabbs wrote:Lobster,
Would you mind adding it to the agenda for me? I'd rather defer the wording to someone else.
http://puppylinux.org/wikka/Foundation006Feb
-
Nathan F
- Posts: 1764
- Joined: Wed 08 Jun 2005, 14:45
- Location: Wadsworth, OH (occasionally home)
- Contact:
Okay, all sounding good so far. Here's a few of my thoughts.
Categories. Should mirror the structure of the menu somewhat, ie office and productivity, games, intenet, network, graphics, system, etc. We will also need a category for libraries and possibly programming languages (could be one category) as there are an increasing number of addons. Certain packages will naturally fall into more than one category and should be listed or at least referenced in as many as they are relevent.
File formats. We will be using dotpups for the concievable future (I'm a realist about this) so keep that open. Squashfiles are becoming increasingly popular and Barry has hinted at the possiblility of using multiple .sfs with Puppy2. As far as unleashed versus .pet/.pget this needs more discussion. If we want click to install capability like in dotpups then we need a new extension to replace .tar.gz. Just as a heads up I'm working on something that is relevent here and could provide a simple method to accomplish both click to install and basic dependency resolution for packages in the unleashed format. Further details on that later but expect a test of the concept in Grafpup-103.
XML versus plain text (possibly comma delimited). I'm a fan of XML myself because as the system evolves we may find a need for some meta data that we forgot to include originally. Easier to add it later with XML without reworking the whole system.
Mirrors. We want as many as possible, but once the system is in place at puppyfiles.us it would be nice if all mirrors could adopt it as well, not sure how this would work and whether or not your system/software contains anything proprietary or non-free so I'm asking and bringing up that issue now. We will also need a way to sync the mirrors on a regular basis. This is a huge chore if done all by hand, and growing by leaps and bounds currently. Juist reread Babb's post and it looks like syncing mirrors is already thought out somewhat, sorry I didn't notice earlier. I could also mirror unleashed packages and dotpups on grafpup.com, but I'm stretched thin when it comes to iso's or squashfiles because of bandwidth issues. So count grafpup.com as another possible mirror site, location is in N Carolina, USA.
I love the idea of upload notification by email or rss. As Babbs and I discussed earlier I was considering setting up an rss feed specifically for Grafpup iso and software releases. It's actually not particularly hard to setup and there's tons of readers available. Mailing lists are also a good idea.
Puppy version information. This should be mainly on developers but testers can be a big help here as well. Main point is that every package should be tested as much as possible and if changes or modifications are necessary in order to get it working on a particular Puppy this should be documented.
That's my thoughts for now. Will be watching anything related closely. Plus I'll do my best to attend the next foundation meeting as well.
Nathan
Categories. Should mirror the structure of the menu somewhat, ie office and productivity, games, intenet, network, graphics, system, etc. We will also need a category for libraries and possibly programming languages (could be one category) as there are an increasing number of addons. Certain packages will naturally fall into more than one category and should be listed or at least referenced in as many as they are relevent.
File formats. We will be using dotpups for the concievable future (I'm a realist about this) so keep that open. Squashfiles are becoming increasingly popular and Barry has hinted at the possiblility of using multiple .sfs with Puppy2. As far as unleashed versus .pet/.pget this needs more discussion. If we want click to install capability like in dotpups then we need a new extension to replace .tar.gz. Just as a heads up I'm working on something that is relevent here and could provide a simple method to accomplish both click to install and basic dependency resolution for packages in the unleashed format. Further details on that later but expect a test of the concept in Grafpup-103.
XML versus plain text (possibly comma delimited). I'm a fan of XML myself because as the system evolves we may find a need for some meta data that we forgot to include originally. Easier to add it later with XML without reworking the whole system.
Mirrors. We want as many as possible, but once the system is in place at puppyfiles.us it would be nice if all mirrors could adopt it as well, not sure how this would work and whether or not your system/software contains anything proprietary or non-free so I'm asking and bringing up that issue now. We will also need a way to sync the mirrors on a regular basis. This is a huge chore if done all by hand, and growing by leaps and bounds currently. Juist reread Babb's post and it looks like syncing mirrors is already thought out somewhat, sorry I didn't notice earlier. I could also mirror unleashed packages and dotpups on grafpup.com, but I'm stretched thin when it comes to iso's or squashfiles because of bandwidth issues. So count grafpup.com as another possible mirror site, location is in N Carolina, USA.
I love the idea of upload notification by email or rss. As Babbs and I discussed earlier I was considering setting up an rss feed specifically for Grafpup iso and software releases. It's actually not particularly hard to setup and there's tons of readers available. Mailing lists are also a good idea.
Puppy version information. This should be mainly on developers but testers can be a big help here as well. Main point is that every package should be tested as much as possible and if changes or modifications are necessary in order to get it working on a particular Puppy this should be documented.
That's my thoughts for now. Will be watching anything related closely. Plus I'll do my best to attend the next foundation meeting as well.
Nathan
Puppy Package Manager System - Update
The online Puppy Package Manager System (PPMS) has taken a twist, please see my post for Feburary 27, below.
The online Puppy Package Manager System (PPMS) has taken a twist, please see my post for Feburary 27, below.
Last edited by babbs on Tue 28 Feb 2006, 02:49, edited 9 times in total.
Paul,
Thank you for your offer of assistance! The files that I am using are php files, but any text editor can make the required changes to them. You may download the English version by clicking on the "English" link provided in my summary above.
By all means, if you have any questions, please PM or email me.
Babbs
Thank you for your offer of assistance! The files that I am using are php files, but any text editor can make the required changes to them. You may download the English version by clicking on the "English" link provided in my summary above.
By all means, if you have any questions, please PM or email me.
Babbs
-
haroldmarshall
- Posts: 2
- Joined: Mon 13 Feb 2006, 17:13
- Location: Waaay out in Illinois country...
Your efforts are particularly important, as illustrated by the recent problems with the GrafPup site. I'm very impressed...thank you for all your work!
I am sometimes asked, " Why do you spend so much of your time and money talking about kindness to the animals when there is so much cruelty to men? " I answer, " I am working at the roots. " ~ George T. Angell
Vietnamese ! Done !
Hi !
Vietnamese ! Finish !
Thanks,
Vietnamese ! Finish !
Thanks,
Just a quick update:
My progress has temporarily stalled. The code that I'm hacking seems overly complex (more so than is probably really needed), and their programming style is very different than mine. I've had to step away from it for a few days so that I can come back at it from a different angle to double check my mods.
My progress has temporarily stalled. The code that I'm hacking seems overly complex (more so than is probably really needed), and their programming style is very different than mine. I've had to step away from it for a few days so that I can come back at it from a different angle to double check my mods.
