Woww, this thread is going quite fast. If I blink once more I'll miss on the fun.
Here are my thoughts:
I am a believer in standards. Standards allow for people to easily transfer their knowledge from one situation to the next one.
There are already a standard app categories and a standard way of organizing them in a flexible way.
It has at least this advantages:
- There is alraedy a standard structure for the Info file for each application. It is called the .desktop file.
- The menu can be reorganized in many different ways having even the ability to have multiple 'views' of the same list of files.
- Writing an XML or HTML or text based on a xdg menu is a snap. (It can be nicely done in less than 50 lines of C code).
- Packages from other distributions already include the .desktop file.
- It's well documented.
- It's based on the 'all packages on the same folder' idea that you've been favouring.
- Puppy is ready to start using xdg menus so creating the .desktop file for each application would facilitate this.
There are other standard ways of categorizing things. I know that to start it always seems easier and more fun to invent your own way instead of learning an existing method. Can you imagine if every car manufacturer or telephone company thought that way?
Something that I haven't seen included on the previous posts, but that has been clearly explained in other threads, is the fact that DotPups are meant to be used as a peer system for sharing packages. This is, an easy way to allow users, even new or non technical users to share packages. It has only one requirement. That it has a dotpup.sh file. That's it, what that file does is up to the creator.
I think it would be a disservice to non technical or casual users that want to contribute to start building requirements around the dotpups.
My vote, (If I have one) is to keep the two tier packaging in puppy:
- dotpups for user contributed packages
- pupgets for 'official' packages.
We could have a 'team' of reviewers and repackagers that could validate and convert the dotpups submited to standardize them.
This way we could still have the best of both worlds: a quick turnaround for new packages for people eager to jump into the latest developments. A trusted set of packages for more conservative people that still want puppy to 'just work'.
Dotpups could still be just posted to the forum and to the original packager discretion, submited for standardization. Remember, not all dotpups are sofware packages.
'Official' packages could go through a three stage process:
Test the contributed dotpup
Convert to the official packaging mechanism with all the standards included.
Review and test the official package.
The best of both worlds.
Discussion: how to categorize packages for end user access?
thanks rarsa (at least for the part that belongs in this topic 
- maybe my idea to discuss things separately is doomed to die anyway)
Maybe the script could even do this: display e.g. all packages tagged 'Screensaver' in the category 'Misc' as long as there are <25 such packages. When the number of packages tagged 'Screensaver' reaches 26 packages, display them at their own (newly generated) category 'Screensaver'.
Is that possible?
(I also browsed their repository via the http mask and it's ... unpleasant... no role model at all)
- maybe my idea to discuss things separately is doomed to die anyway)that's great - I'm all for following this standard! If I didn't make an error that's 115 categories, so I would propose we tag the packages using this system and have an access side script that sorts them into a bit fewer 'main categories'.rarsa wrote:There are already a standard app categories and a standard way of organizing them in a flexible way:
http://standards.freedesktop.org/menu-s ... t/apa.html
Maybe the script could even do this: display e.g. all packages tagged 'Screensaver' in the category 'Misc' as long as there are <25 such packages. When the number of packages tagged 'Screensaver' reaches 26 packages, display them at their own (newly generated) category 'Screensaver'.
Is that possible?
I have been told the 'official' packages are truly the unleashed ones. So we have three package types at the moment. The idea is to reduce that to two by combining pupget&dotpup ideas. what your proposed team of reviewers could do is decide which submitted packages are worthy to be made unleashed packages, that are optionally fully integrated into puppy).rarsa wrote:My vote, (If I have one) is to keep the two tier packaging in puppy:
- dotpups for user contributed packages
- pupgets for 'official' packages.
those are mostly the ones that should not register with pupget anyway, right?Remember, not all dotpups are sofware packages.
there is a lot into this, it seems to me. you would need a set of rules (when is a dotpup properly tested etc) and a team of dedicated, coordinated people working on this. How is this managed at other smaller distributions like DSL? they have an "official mydsl repository" and only warn about the apps in 'testing'. Anybody with more info about their testing process?'Official' packages could go through a three stage process:
Test the contributed dotpup
Convert to the official packaging mechanism with all the standards included.
Review and test the official package.
(I also browsed their repository via the http mask and it's ... unpleasant... no role model at all)
I think it would be better to just stick to the main categories (the 'Related' on the right side), and keep things like 'ScreenSaver' a subcategory.that's great - I'm all for following this standard! If I didn't make an error that's 115 categories, so I would propose we tag the packages using this system and have an access side script that sorts them into a bit fewer 'main categories'.
Maybe the script could even do this: display e.g. all packages tagged 'Screensaver' in the category 'Misc' as long as there are <25 such packages. When the number of packages tagged 'Screensaver' reaches 26 packages, display them at their own (newly generated) category 'Screensaver'.
Else, user might suddenly find: "Oh, where did that category go? Oh, and what's that other category doing in here?"
@Rarsa: I love the ideas! I think that's the way the whole process is handled in Debian and Gentoo.
Sounds great
ps: I feel like spamming the thread, sorry for that.
I had a system of just one category level in mind, if the system would include subcategories your approach is much better. 'Screensavers' should not appear between 'System' and 'Utilities' in the upmost level then, but on a sublevel (but of what? - in Rarsa's link there is no related category for that - 'Misc', I guess).Mathiasdm wrote:I think it would be better to just stick to the main categories (the 'Related' on the right side), and keep things like 'ScreenSaver' a subcategory.
Else, user might suddenly find: "Oh, where did that category go? Oh, and what's that other category doing in here?"
My idea could work nevertheless to keep the number of subcategories small (e.g. 'game' category doesn't need 12 subcategories, when there is only 1 'action game' available.)
And of course no categories should disappear, be renamed or moved once the system is up and running, that's why a prior discussion about it seemed necessary to me. Creating new categories later on the other hand might be more useful than filling the main categories with empty subfolders (which maybe never fill (like screensaver
) right now.
So we need clarification about what would be possible (in terms of reasonable effort) with an access tool / webmask - multi-level categories or just one level? (please note I don't talk about the actual server layout here, for the moment I assume a single folder containing all files is the way to go, disabling simple ftp access).I should have been more explicit:
It took me some time to understand the Freedesktop XDG menus specification.
Under the standard the categorization and organization are two distinct tasks.
Categories are a property of the package:
This is, at one level a package can be categorizad as "TextEditor, Utility", or as "Network, WebBrowser" Or in your example, a screen saver could be categorized as "Settings, DesktopSettings, Screensaver"
An XDG file organizes packages based on category rules
This is, you just specify in the rules (the XDG file) what categories go under what entry.
For example, you can say that under "Settings" you want all the packages that have the 'Settings' category but not the 'Network' Category.
So you can have an almost flat structure with like in Puppy (control panel, setup, Text editor, Internet, etc)
Or you can have a more segmented organization (like KDE)
All using the same categories, just with different rules to group them.
What's more, it is possible to have the same package under two different entries based on the rules.
Many people have put a lot of thought into this and came up with a simple and powerfull solution.
Here is a sample of what it would look like the Organization rules for The networking tools in Puppy. Under the Network entry we include everything that's categorized as "Network" and "System", under the Internet entry, we could include everything that's categorized as "Network" and not categorized as "System":
It took me some time to understand the Freedesktop XDG menus specification.
Under the standard the categorization and organization are two distinct tasks.
What's more, categorization is based on a combination of categories, not on a single category.The menu can be reorganized in many different ways having even the ability to have multiple 'views' of the same list of files.
Categories are a property of the package:
This is, at one level a package can be categorizad as "TextEditor, Utility", or as "Network, WebBrowser" Or in your example, a screen saver could be categorized as "Settings, DesktopSettings, Screensaver"
An XDG file organizes packages based on category rules
This is, you just specify in the rules (the XDG file) what categories go under what entry.
For example, you can say that under "Settings" you want all the packages that have the 'Settings' category but not the 'Network' Category.
So you can have an almost flat structure with like in Puppy (control panel, setup, Text editor, Internet, etc)
Or you can have a more segmented organization (like KDE)
All using the same categories, just with different rules to group them.
What's more, it is possible to have the same package under two different entries based on the rules.
Many people have put a lot of thought into this and came up with a simple and powerfull solution.
Here is a sample of what it would look like the Organization rules for The networking tools in Puppy. Under the Network entry we include everything that's categorized as "Network" and "System", under the Internet entry, we could include everything that's categorized as "Network" and not categorized as "System":
Code: Select all
<Menu>
<Name>Network</Name>
<Directory>Network.directory</Directory>
<Include>
<And>
<Category>Network</Category>
<Category>System</Category>
</And>
</Include>
</Menu>
<Menu>
<Name>Internet</Name>
<Directory>Internet.directory</Directory>
<Include>
<And>
<Category>Network</Category>
<Not>
<Category>System</Category>
</Not>
</And>
</Include>
</Menu>
Sounds nice 
I hope you don't mind me proposing a little scheme
I plan on using it (or something like it) in my own distro (currently not existing yet)
Let's describe (it looks a bit crazy ).
Just the standard beginning. Could be another version is needed
The package maintainer and his/her information.
Includes the name, the comments (technical) and the last time he/she has worked on the package.
Package description.
Includes:
-name
-version
-release date of that version
-description (with the option of describing in several languages!
-the homepage
-the license
-the arch (not really needed for puppy right now, but perhaps in the future (always be prepared!)
-marked: stable, testing, unstable (this way, people can choice what type of packages they want to use
Package category. Tricky one!
It includes the location in the filesystem hierarchy in the <location> tag.
The main location (highest level) is included in the tag itself, using main="blabla" .
The sub-location is included between the two tags.
Then there's the category list.
This is how it appears for the user.
Once again with the main category and the sub-category.
The dependency list...
It includes every program that needs to be fetched before installing the program itself.
It includes:
-the location of the dependency
-the name
-the minimum version that works with this package
-the maximum version that works with this package
-the versions inbetween that don't work (<exclude> tag)
-the versions NOT inbetween that DO work (<include> tag)
So...
What do you guys think?
I hope you don't mind me proposing a little scheme I plan on using it (or something like it) in my own distro (currently not existing yet)
Code: Select all
<?xml version="1.0" encoding="ISO-8859-15"?>
<package_info>
<package_maintainer>
<maintainer_name>Mathiasdm</maintainer_name>
<maintainer_comments>Damn, had to do lots of work on this one!</maintainer_comments>
<maintainer_last_update>2006-01-19</maintainer_last_update>
</package_maintainer>
<package_description>
<package_name>PackageExample</package_name>
<package_version>1.0</package_version>
<release_date>1566-12-12
<description lang=en>This is a pretty amazing package!</description>
<description lang=nl>Een fantastisch programma!</description>
<package_homepage>http://an_amazing_package.com</package_homepage>
<package_license>GPL-2</package_license>
<arch>x86</arch>
<marked>stable</marked>
</package_description>
<package_category>
<location main="Development">IDE</location>
<category_list>
<category main="Gnome">GTK_tekst_editor</category>
<category main="KDE">QT_tekst_editor</category>
</category_list>
</package_category>
<package_dependencies>
<dependency>
<location main="Development">IDE</location>
<package_name>Eclipse</package_name>
<min_version>1.0</min_version>
<max_version>3.1</max_version>
<exclude>3.0</exclude>
<include>4.11</include>
</dependency>
<dependency>
<location main="Development">Debugger</location>
<package_name>WindowsBlackComb</package_name>
<min_version>20.1</min_version>
<max_version>22.1</max_version>
<exclude>21.0</exclude>
<exclude>21.2.0</exclude>
<include>3.11</include>
</dependency>
</package_info>Let's describe (it looks a bit crazy
).
Code: Select all
<?xml version="1.0" encoding="ISO-8859-15"?>Code: Select all
<package_maintainer>
<maintainer_name>Mathiasdm</maintainer_name>
<maintainer_comments>Damn, had to do lots of work on this one!</maintainer_comments>
<maintainer_last_update>2006-01-19</maintainer_last_update>
</package_maintainer>Includes the name, the comments (technical) and the last time he/she has worked on the package.
Code: Select all
<package_description>
<package_name>PackageExample</package_name>
<package_version>1.0</package_version>
<release_date>1566-12-12
<description lang=en>This is a pretty amazing package!</description>
<description lang=nl>Een fantastisch programma!</description>
<package_homepage>http://an_amazing_package.com</package_homepage>
<package_license>GPL-2</package_license>
<arch>x86</arch>
<marked>stable</marked>
</package_description>Includes:
-name
-version
-release date of that version
-description (with the option of describing in several languages!
-the homepage
-the license
-the arch (not really needed for puppy right now, but perhaps in the future (always be prepared!)
-marked: stable, testing, unstable (this way, people can choice what type of packages they want to use
Code: Select all
<package_category>
<location main="Development">IDE</location>
<category_list>
<category main="Gnome">GTK_tekst_editor</category>
<category main="KDE">QT_tekst_editor</category>
</category_list>
</package_category>It includes the location in the filesystem hierarchy in the <location> tag.
The main location (highest level) is included in the tag itself, using main="blabla" .
The sub-location is included between the two tags.
Then there's the category list.
This is how it appears for the user.
Once again with the main category and the sub-category.
Code: Select all
<package_dependencies>
<dependency>
<location main="Development">IDE</location>
<package_name>Eclipse</package_name>
<min_version>1.0</min_version>
<max_version>3.1</max_version>
<exclude>3.0</exclude>
<include>4.11</include>
</dependency>
<dependency>
<location main="Development">Debugger</location>
<package_name>WindowsBlackComb</package_name>
<min_version>20.1</min_version>
<max_version>22.1</max_version>
<exclude>21.0</exclude>
<exclude>21.2.0</exclude>
<include>3.11</include>
</dependency>It includes every program that needs to be fetched before installing the program itself.
It includes:
-the location of the dependency
-the name
-the minimum version that works with this package
-the maximum version that works with this package
-the versions inbetween that don't work (<exclude> tag)
-the versions NOT inbetween that DO work (<include> tag)
So...
What do you guys think?
Well, seeing as nobody really seems to be interested, I fear a package manager might be far awayFlash wrote:I think you're going to have your work cut out for you, first to make sure that everyone who develops software for Puppy is aware of this index or database, and then to convince them to agree to keep it up.
Flash - Good question.
As I've said routinely, in addition to Puppy, I use Fedora Core 3. (As far as I can recall, I'm the only one on this forum that admits to this.) The packages packaged for Fedora routinely come with the extension of .rpm and are installed pretty much the same way .tar.gz packages are installed in Puppy.
I feel pretty confident in saying that there are probably over a thousand rpm packages for Fedora (houndreds for each version of Fedora). With that many packages to consider, each with unique or duplicitive functions, a system to install, update and delete them was needed.
This is where the package manager YUM (Yellow Dog Updater, Modified) comes into play. Although I know that there are other package managers out there like "apt", but this is the one I use. To use YUM in Fedora, as root at the command line, I issue the command "# yum list updates" to see what has been updated. There are other options like "# yum list" to see what packages are available, and "# yum list installed" to see what has been installed. With YUM, you can update individual packages or all of them at once. (You can also use YUM to removed packages.) In addition to listing/installing packages, it also manages dependancies.
The file yum.conf contains a list of repositories that are checked for updates. Yum checks the headers at the repositories against the headers on the local box to obtain its information for what is installed and what needs to be updated.
The problem with YUM is that you have to know what each file, by name, is and what it does. The solution to that is a gui called Yum Extender (YUMEX). With YUMEX, you can select what repositories to use (and not to use); install, update, remove packages from list of availble packages; repository editor; packages search features; and best or fastest mirror detection. For me, the best reason to use YUMEX is that it also has a summary of what each package is and how big the file is.
With only a few packages, a package manager is not needed, but as Puppy grows and grows, I think some sort of package manager is needed. I don't know if the YUM/YUMEX model is one worth looking into, but it was an example with which I am familure.
Does that help any?
Babbs
YUM - http://freshmeat.net/projects/yum/
YUMEX - http://linux.rasmil.dk/yumex
As I've said routinely, in addition to Puppy, I use Fedora Core 3. (As far as I can recall, I'm the only one on this forum that admits to this.) The packages packaged for Fedora routinely come with the extension of .rpm and are installed pretty much the same way .tar.gz packages are installed in Puppy.
I feel pretty confident in saying that there are probably over a thousand rpm packages for Fedora (houndreds for each version of Fedora). With that many packages to consider, each with unique or duplicitive functions, a system to install, update and delete them was needed.
This is where the package manager YUM (Yellow Dog Updater, Modified) comes into play. Although I know that there are other package managers out there like "apt", but this is the one I use. To use YUM in Fedora, as root at the command line, I issue the command "# yum list updates" to see what has been updated. There are other options like "# yum list" to see what packages are available, and "# yum list installed" to see what has been installed. With YUM, you can update individual packages or all of them at once. (You can also use YUM to removed packages.) In addition to listing/installing packages, it also manages dependancies.
The file yum.conf contains a list of repositories that are checked for updates. Yum checks the headers at the repositories against the headers on the local box to obtain its information for what is installed and what needs to be updated.
The problem with YUM is that you have to know what each file, by name, is and what it does. The solution to that is a gui called Yum Extender (YUMEX). With YUMEX, you can select what repositories to use (and not to use); install, update, remove packages from list of availble packages; repository editor; packages search features; and best or fastest mirror detection. For me, the best reason to use YUMEX is that it also has a summary of what each package is and how big the file is.
With only a few packages, a package manager is not needed, but as Puppy grows and grows, I think some sort of package manager is needed. I don't know if the YUM/YUMEX model is one worth looking into, but it was an example with which I am familure.
Does that help any?
Babbs
YUM - http://freshmeat.net/projects/yum/
YUMEX - http://linux.rasmil.dk/yumex
A package is a distribution-specific software-"zip" (called .deb on Debian or .rpm on Suse, Mandriva, RedHat).
Different to normal zips, it includes some additional informations.
These contain information about dependencies (what libraries are required to run the software).
When you install a package, this information is added to the distributions database.
So if software1.rpm needs libXYZ, and software2.rpm needs that, too, both add that to the database. And the "Packagemanager" will automatically install this required library libXYZ.
Now when you uninstall software1.rpm because you don't need it any more, the libXYZ will not be deleted, because your software2 still needs it.
Just if you also uninstall software2, also libXYZ will be deleted too, because now it is not needed any more.
So this database-functionality is the big difference to dotpups for example (and to Windows) .
Mark
Different to normal zips, it includes some additional informations.
These contain information about dependencies (what libraries are required to run the software).
When you install a package, this information is added to the distributions database.
So if software1.rpm needs libXYZ, and software2.rpm needs that, too, both add that to the database. And the "Packagemanager" will automatically install this required library libXYZ.
Now when you uninstall software1.rpm because you don't need it any more, the libXYZ will not be deleted, because your software2 still needs it.
Just if you also uninstall software2, also libXYZ will be deleted too, because now it is not needed any more.
So this database-functionality is the big difference to dotpups for example (and to Windows) .
Mark
-
Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
I refuse to believe that I am more intelligent than an orange.
Thanks Mark - I gets it. Hopefully Flash will too.
From what you are saying .pet is best created with a form
Best saved/mirrored in a manner related to that form
Best displayed in a variety of ways dependent on end users requirements.
Would that be a reasonable spec?
This seems an excellent format to start with as does the XML
suggestion
Thanks Mark - I gets it. Hopefully Flash will too.
From what you are saying .pet is best created with a form
Best saved/mirrored in a manner related to that form
Best displayed in a variety of ways dependent on end users requirements.
Would that be a reasonable spec?
Package description.
Includes:
-name
-version
-release date of that version
-description (with the option of describing in several languages!
-the homepage
-the license
-the arch (not really needed for puppy right now, but perhaps in the future (always be prepared!)
-marked: stable, testing, unstable (this way, people can choice what
type of packages they want to use
This seems an excellent format to start with as does the XML
suggestion
- Attachments
-
- xml.jpg
- (46.92 KiB) Downloaded 525 times
The problem with .pet and dependencies is, that pupget has no mechanism to handle dependencies.
As far as I understood a message from bombayrockers, it can already detect missing dependencies, but there is no database managing them.
So I would suggest to ignore dependencies in first versions of .pet.
This would allow backward-compatibility to older Puppys, too.
You just had to add a new mime-type to ROX, so that you can install them with a mouseclick.
However, if someone has the power to add advanced dependency-handling, that would be great.
I am currently in some financial trouble, and will have to spare some time with web-development to earn some bucks.
So I cannot say yet, when I can contribute programs for .pet
Mark
As far as I understood a message from bombayrockers, it can already detect missing dependencies, but there is no database managing them.
So I would suggest to ignore dependencies in first versions of .pet.
This would allow backward-compatibility to older Puppys, too.
You just had to add a new mime-type to ROX, so that you can install them with a mouseclick.
However, if someone has the power to add advanced dependency-handling, that would be great.
I am currently in some financial trouble, and will have to spare some time with web-development to earn some bucks.
So I cannot say yet, when I can contribute programs for .pet
Mark