apps vs packages focus of the repo

[levi]

Yes, apps have likes (which have replaced ratings in every prototype repo thus far) but packages do now. See this app which has 5 likes at time of writing, shown in the blue like box top right at present. Versus this package which doesn't have a blue like box. It does show you that the app it contains has 5 likes, but you can't add a like until you navigate back through to it.

I'm okay with likes replacing ratings by the way. I always feel a bit of a sod if I rate anything other than 5 stars on the old repo.

 

[Silent-Hunter]

I just want to mention that a package view should be fine, if more than one program is in a single package then they're likely related, which means it should be alright for likes to apply to the package and thus all apps inside it.

 

[_jr_]

Won't the dependency system simplfy things...

I think this is the core issue. Adding something (e.g. dependencies) makes the meta model more complex. This can be a good thing if, and only if this then more closely resembles the thing to be modeled (e.g. user's expectations).

To me the repo contains things ('cartridges') that I can download to removable storage. If the medium containing this cartridge is attached to my system it will add one or more icons to my desktop that I can interact with. When i activate such an icon something cartridge specific will happen.

Packages that create no icons on my desktop would be difficult to manage, because being effectively invisible would make it more difficult to ensure that I have the correct media attached (I cannot even easily see on which medium it is stored.

I suspect it would be easier for me (though technologically much less elegant) to have the dependency management embedded in the cartridge (like now in the PND system, but with better support for discovery and on demand mounting/unmounting of cartridges) if at all necessary instead of a generic mechanism (not saying though that there are no use cases for a generic mechanism).

Therefore I voted for a package centric repository. Perhaps instead of an 'app' concept (which would probably require new metadate since probably not every provided icon will qualify to be an 'app') a package could provide a list of content describing tags that could be optionally attached to likes and comments. That allows finer granularity in searches and user generated content without complicating the core dbp mechanism (i.e. downloading things to removable storage, managing things on removable storage, and running things from removable storage).

 

[sebt3]

Packages that create no icons on my desktop would be difficult to manage

dbp-get.sh do all the download for you, dbpd ensure you have all you need. There's no management on the user side. That's the reason why handling the dependency the way it is done for the dbp system is far superior to the pandora way.

I suspect it would be easier for me (though technologically much less elegant) to have the dependency management embedded in the cartridge (like now in the PND system, but with better support for discovery and on demand mounting/unmounting of cartridges) if at all necessary instead of a generic mechanism (not saying though that there are no use cases for a generic mechanism).

Handling the dependencies the pandora way is the worst shit ever. Beside it break the cartridge metaphor because any way you handle the dependencies, the package is not stand-alone anymore.

Handling an issue manually instead of relying on the tools that does it for you is never "easier", otherwise the tools wouldnt be there

 

[_jr_]

Handling an issue manually instead of relying on the tools that does it for you is never "easier", otherwise the tools wouldnt be there

Then I suspect we won't be able to agree on much concerning software engineering

 

[levi]

I think it's a matter of the user asking for what the user wants, and the computer does what's necessary to filfil that requirement. Dependencies were deemed a good thing because we got into a situation with the Pandora's PNDs that more and more libraries needed to be put inside PNDs as time went on, and newer source code requires newer libraries more often. Many of those libraries are the same across different PNDs, you just download them over and over again as you download different PNDs.

Increased internet speeds and card sizes means this hasn't been such a limiting factor, but even if nobody's on a slow link these days (which I doubt personally) it's still good practice to eliminate duplication. That's what dependencies do.

The user asks to install a package, and dbpd ensures you get that package and also any needed to make it work. As a user you don't need to be concerned with the backend stuff, which is all handled for you. We had this debate a long time ago in the linux community - when dependency management appeared, plenty of people sniffed at it, but all popular linuxes these days have full dependency management. Even linux users prefer having this stuff handled for them.

 

[Christoph.Krn]

Your question concerns the user's ability to grasp what exactly it is that the repository delivers, down to the level of an individual entry. Because both concepts, Package and App, do exist and will not go away, I would first try to make the distinction between these two understandable in an intuitive way.

To a new user, the difficult thing is that very distinction (or, even knowing that it exists in the first place). Once it is understood, there may not be a significant problem (though I'm making a guess here based in the assumption that multi-App Packages will not be the norm anyway).

As for how exactly the distinction can be conveyed in intuitive ways without necessitating a manual for the repository, one idea could be to list Packages, but if a Package has multiple Apps, list each App instead, and display the name of each as something like "Game Name - Software 1/2 in examplepackage.dbp", "Game Name Level Editor - Software 2/2 in examplepackage.dbp".

I'm tending towards stating that every Package should have its own page (which lists and shows information about all Apps of the Package, if there are several), but individual Apps should not. It may be difficult to convey the latter concept, and at the current time, personally I do not expect packages with many Apps inside to become a very regular sight. I may be wrong, of course.
Not to mention, one page per Package is Neat™, and that is not to be underestimated...

 

[levi]

I tend to thing the repo goes a good way to educating us about the difference as is. It shows apps by default (at present) and when you click through to them it tells you that they're delivered inside a package. If you don't care, you can just hit the download button and it'll give you the package that contains the app the page you're viewing is about.

Your proposal (show packages, but multiple entries for multi-app packages) is the same as showing all apps, but additionally including packages that have no apps (the pure engines) FWIW.

 

[elvissteinjr]

So what happens when I try to launch a dbp I don't have the dependencies for? Will I get told off? Will it download them automatically? Or will I have to launch the app in a terminal/check log files to even see that it may be complaining about missing shared libraries?
My router's wifi is far from reliable so I prefer downloading the stuff on my PC usually. Wifi on mobile devices is usually turned off unless required. This habit probably won't change for the Pyra unless I'm forced to.

Regarding the actual topic, I don't know. Ratings and comments should belong to what the user is intending to download... so uh, apps... or packages? I'm not helping, I know.

 

[levi]

The dbp mounter should tell you of any missing dependencies if you've manager to download just a package without its dependencies. It's a little like debian packages - under normal usage it's designed to run on a networked system and download and install packages and their dependencies automatically, but if you do do the extra work to get a raw .deb file you want, it simply won't install if you haven't got the dependent packages already installed.

Pyra dbp's aren't installed in the same way as debian .deb files are - they're just dropped on an SD card and dependencies are only actually handled when you try to run them, so if you're missing dependencies then it should tell you and stop launching the dbp.

Actually, I don't think the app view shows you anything the package depends on. That could be considered a downside of the app view, for people downloading packages on a different system to use on Pyra later, right?

 

[sebt3]

This is what I get when trying to run a app without it's dependency.


I doubt the button install works just yet, but clearly that's planned

EDIT: and the app page on the repo do show the dependencies : https://pyra-handheld.com/repo/apps/18
and can add a box to show if an app is part of a bundle

 

[levi]

Oh right, apps show dependencies, but they don't show the package they belong to any more? Has that changed? I can see that standalone apps do show their packages, but it seems apps that have packages that also depend on packages only show their dependencies. That doesn't fit with my idea of the app to package transition being always a click away.

 

[milkshake]

Don't know if it's already been answered but what if you have an app that depends on a older version of an engine? Mono or java or some game engine.

Will you end up with multiple versions of the engine installed to satisfy each dependency from an application or will your app try and use the latest version even if it's not really compatible?

 

[PowerGod]

Don't know if it's already been answered but what if you have an app that depends on a older version of an engine? Mono or java or some game engine.

Will you end up with multiple versions of the engine installed to satisfy each dependency from an application or will your app try and use the latest version even if it's not really compatible?

I did that question regarding DosBox here https://pyra-handheld.com/boards/threads/dosbox-dbps.81983/#post-1425723

and in short the answer was that IF something like that happens, could be made a different package containing both the game and the engine

 

[milkshake]

Doesn't that go against the idea of having dependant packages?

 

[PowerGod]

Doesn't that go against the idea of having dependant packages?

As far as I understood, it is possible to just make another package for the old engine (with the file name containing the fixed version, just to make it different from the always-up-to-date-standard-engine), and then link the game to it.

The linked discussion maybe was more on the "Is it REALLY needed an old version ??!!" side...

So maybe there's just the need for a real known existent situation to try out the best standard way to manage that.

 

[levi]

Yeah, in systems like debian's .deb repository, if an old dependency is ever needed, the new dependency is usually given a new name. For example, there are gtk2 and gtk3 packages, and some apps are dependent on one and some the other.