Getting software onto Pyra


Maquis196

Member
Joined
Oct 7, 2011
Messages
182
Location
London, UK
Afternoon all, long term lurker and someone who has both pandora and pyra and wanted to share some thoughts.

I do apologise if this has been spoken about elsewhere but as someone finally getting software onto my pyra I am thinking about this, and ftr, I'm a devops by trade so I see pipelines config-as-code everywhere!

So basically I understand why we have the .dbp/.pnd files, and I get the whole "shop front" experience from the pyra repository, but I recall from the pandora days that someone would almost "grab" an application and upload their version and if they then dropped off the radar, we'd end up with multiple versions of that application and/or it was never updated.

So I'm wondering why we don't have a more "Gentoo/FreeBSD" type system where each app is in a git repo somewhere, patches/versions all handled there. When updated some pipeline somewhere releases a new dbp/pnd/deb release and then each software version can be bumped by anyone and then approved by someone to make it live?

Or say like how they have it on the MisterFPGA cores where each core is its own repo and then when updated, it releases the new file for people to download (plus maybe automatic updating of the pyra repo also?).


So yeah, apologies again if this has been discussed elsewhere, but im genuinely curious? Or would anyone be interested in something like this going forward?
 
Further to the above, with arm runners, might not even need a pyra/emulation to build a new package natively. Although I have some experience with building other platform binaries using docker and cross compiling. So could be a docker image is made to build what we need anywhere, then suddenly I'd expect most things to be easily kept up-to-date easily, as long as the git repo is looked after, could be built either say github/cloudci (potentially for free, but ymmv)
 
I recall from the pandora days that someone would almost "grab" an application and upload their version and if they then dropped off the radar, we'd end up with multiple versions of that application and/or it was never updated.

The situation with Git could be exactly the same, I make a project and abandon it, someone fork it and asks for a push that will never be accepted, and that's it two version of the same program around.
 
The situation with Git could be exactly the same, I make a project and abandon it, someone fork it and asks for a push that will never be accepted, and that's it two version of the same program around.
This is why it would need to be officially "owned" by the project, like how the repo is. Anyone could fork it, release their own (bonus points if the same workflow means you dont have to think about it), but least anyone could do the PR to bump a version and tweak whats there to release a newer one.

So sure, would need people whose role it is to approve such updates, but if a pipeline goes green to show it works, its a tick of a button. Without worrying about people abandoning it, etc
Post automatically merged:

also, I can see we have some semblance of this already;

 
I had the same idea. A few dbp's have link errors that I could fix if I had the code.
 
Oh if we would only have something like you know a repo, like debian has.

Joke aside, the pandora/pyra package system is meant for games. We only kinda suck it releasing them as such.
And for games you cant apply the same logic as for general software.
Eg some of our pnds are exclusive and the author did not want to share sources.
 
Looking at the above dosbox example, I can see that the "new" pyra repo at least can handle multiple contributors. Perhaps if a release to it can be automated to the repo, we could have everything in the backend (whatever repo at whichever ci) so that were one PR away from a latest release. I'll set up a couple as working examples, but would rather there were some kind of "semi official" org/repo for said work, perhaps it doesnt matter if we can all fork/release whenever.
 
Back
Top