To be honest I think trying to include other package dependencies makes this complicated than it should be. And in most cases everything is on pandora to anyways. If im missing a library that is not in the firmware I include in the pnd. So i think for very many of existing pnds they just run.

I think this should be kept simple and just be used to verify data content.


From: Sébastien Huss <sebastien.huss@gmail.com>
To: firmware-dev@openpandora.org
Sent: Tue, September 20, 2011 5:42:01 PM
Subject: Re: [Firmware-dev] requirements element i PXML?

Hi there,

If we only want to inform the users before hand, then why indroducing yet others fields (that dev have to take care of, front-ends too ; what about these ~400 already exisint PNDs) when the current one could be used. 
The package description could already include that. I think the issue is more that, like pickle said, most dev are lazy on the instructions side (at least I do too).

If we want it on the pandora side, then I'll agree with Jeff : it should be part of the run script in the PND as we dont want to create a new language for describing all these dependencies.

Maybe, we need to communicate more to the devs on "how to package your apps/games in a PND cleanly" 

Cheers,
sebt3
2011/9/20 skeezix <skeezix@skeleton.org>
On Tue, 20 Sep 2011, Scott Smith wrote:

# I think i brought up this problem when the pnd system was first being
# introduced, but it didnt really go anywhere. I also have to admit ive
# been a bit lazy on instructing the user on what files are need and
# where. Most of the time I wrote something up quick and sweet in a
# readme. As a result I have seen threads/comments by confused users on
# what to do.
#
# Originally I wanted a mechanism in the pxml that could contain a list of
# files, which the system would look for and report back to the user. (I
# think i still like this method) Ive used some pnd's do their own checks
# (assume through scripts and zenity) and do not run until all required
# files are present. Maybe something as simple as a identifier that a pnd
# requires data that is not included, and the user is directed where to
# find the details on the data.

       Thought I originally had was a standard way to present info to the
user (which turned into zenity, which is ugly but functional) and then
folks run-scripts _should_ do the reporting; ie: since each app is so very
different, and without wanting to create a whole language to describe
requirements, I figured that was the way to go..

       .. but alas, so few apps actually do that (or do it well), and of
course the problem where the user may want to know _in advance_ (ie: not
on pandora, but from the repo or whatever.)

       The next idea that came along was 'long description' and 'short
description' or perhaps 'short', 'long', 'install' -- multiple levels of
description in the PXML (by language like everything else), with repos and
package managers chosing which set to show.

       We did add a 'requirements' crappy thing, where the PXML can say
'I need X11' and that sort, but never went very far there either.

       --

       I'm a fan of having the multiple descripotion levels, myself--

       i) existing description which is 'free form'; can be short or
long, so assume this is the 'full description' for compatibility
[       ii) A 'short desc' which is 'required' (in the spec at least,
perhaps enforced by libpnd) to be 'one sentence' or something; something
required ot be short and presentable in a list on small screen/website.
       iii) install information

       Note that we have..

       <descriptions>
               <description...>
       </descriptions>

       We could add in other types, right there:

       <descriptions>
               <description...>
               <installhelp ...>
               <short ...>
       </descriptions>


               jeff