"ext Steve Greenland" <steveg at moregruel.net> writes: > According to Marius Vollmer <marius.vollmer at nokia.com>: >> How important is it to fix this? I'm working on the assumption that >> you would only activate "Show all packages" in an emergency, but would >> usually leave it off (precisely because it decreases the useability so >> much). > > The problem is that while in theory, I could just display all the > packages in a particular cagetory, or even only the "users/*" > categories, in practice the category stuff is so screwed up that the > only way to find anything is browsing the "all" lists. Browsing the "All" category and the "Show all packages" settings are two different things. (I am not sure whether you are aware of that.) Activating the "Show all packages" setting will list all packages in the package database, between 1000 and 2000 or so. This is what is unacceptably slow. Deactivating "Show all packages" and browsing the "All" category should give packages in the small hundreds or so, and that should be OKish performace wise. No? > This screwup isn't your fault, of course; it's the lack of having a > standard policy document to guide developers. Even what there is isn't > consistent. Consider the 3-.x "Making a package for the Application > Manager in maemo 3.x" document. It says: > > The AI only shows packages in the "user" section. Thus, your > "Section:" field in the control file should be of the form > "user/<SUBSECTION>", where SUBSECTION is arbitrary. SUBSECTION > should be a nice capitalised, English word like "Ringtones" > > Then it shows examples like: > > # user/accessories Accessories > # user/communication Communication > > So, what goes in the control file? "user/accessories" or > "user/Accessories" or "user/accessories Accessories"? Two of the three > violate the previous definition, and the examples don't even follow the > form. You misunderstood. The list is not a list of examples, it is a list of predefined categories that you should use whenever possible. The predefined categories are also localized. I hope the document that you refer to is not screwed up. I will check myself. > Writing policy (standards, basically) is hard, of course. (I was > involved in a lot of the early Debian policy documentation.) But to > have a working thirdparty developer community, it's necessary. A > complete anarchy does not lead to good results. Yes, but the Application Manager is not the one enforcing policy. If it encounters a non-policy-conforming package, it will still show and install it if possible. (And no, not-installing packages that don't have the "user/foo" section marker is not about enforcing policy, it is about "enabling a nice and non-confusing UI experience". :) > At lot people miss the fact that the reason Debian packages have such > a good reputation (compared to RPMs, particulary RPMs from the Redhat > 5-8 era), has very little to do with the technology of .deb and a huge > amount to do with the Debian policy effort. Yes, this point merits repeating.
