DBP repository

[RubisDrake]

I hate to ask this, but will this be sort of an App store implementation to install programs from, or just an extra repo?

And will this be a repo that anyone can add to Debian's sources.list, for example?

 

[levi]

It's not a sources.list type of repo no, it's more like an app store. The pyra will have a command line and probably a graphical tool to let you search and install apps and their dependencies, but I think they'll be installed as a set of .dbp files, probably on an inserted SD card rather than part of the persistent root filesystem. Assuming they're like the Pandora's PND files a little, they'll actually be mountable squashfs isos.

They're a little like docker containers, but instead of containing all the libs and so on they need, they're designed to use libs from the base filesystem as well as any extra ones they ship. But it means you can eject the SD card and still boot the OS.

It remains to be shown how actual software authors will decide to release stuff, either as a dbp or push it into the debian repos for installation to the OS on the internal flash. On the Pandora we got a PND for Firefox for example - I'm not sure how much sense it makes to have someone publishing firefox as a DBP when we can just use iceweasel, updated by someone in the wider Debian community rather than waiting for someone from our community to build a version. But some people won't want the flash traffic that a browser like that will have on their flash chip (although on the Pyra, that can be bypassed using a microSD card at least, if it does die on us).

 

[_jr_]

Adding to Levi's explanation: the idea as I see it is not primarily a closed app store eco system, but a way to manage applications installed on removable storage, because internal storage is limited (though not as severely as on the Pandora). Still it is mostly about convenience and not about security or devops. So, while there is an overlap with other solutions like flatpack it seems there is a place for a system specialized to the Pyra niche. As Levi said, we'll see how it will work out.

 

[Binky]

Part of the problem is that Debian package management, while wonderful, doesn't provide any facility for installations split across disks, where one of the disks may be removed or replaced at any time.

The idea is to have a core installation (including a desktop env, and some applications) installed on the (fast) built-in eMMC, and then a SD card full of DBP files.

DBPs will generally be user-facing games and applications, mostly dependant on common libs in the core installation, and will rarely(?) depend on each other.

The main reason to use DBPs instead of Debian packages is to save space and wear on the Pyra's internal memory. In the case of the Pandora, we only have 500MB internally - which is clearly not enough for a complete linux installation with hundreds of games.

Since DBPs are not (and cannot be) Debian packages, a different repo, and a different package manager are needed. That said, a DBP is a self-contained file, so most operations on them can be performed with your favourite file manager anyway.

Any native package manager for DBPs should support third-party repos, if anyone feels like hosting one.

 

[sebt3]

Changes since last status report :

• Fix the download file issue (reported by levi)
• RSS feed
• Delete package
• Disable package/app/version
• Made the left bar larger on medium sized display

Still todo :

• Fix the carroussel in tab bug
• Make a better app page (mockup welcome)
  
• Make a better package page (mockup welcome)
• improve apps list

Since only one have packages, here is the package edit page maitainers have acces to :

 

[Binky]

Please tell me "Pedentic English" (in the US translation) is a joke...

 

[sebt3]

Please tell me "Pedentic English" (in the US translation) is a joke...

You had no issue with the "simplified english" as american in the british translation though...
Joke reverted.
Beside, the only difference between these 2 languages is the spelling of "licence"...

 

[Binky]

I've no problem with "pedentic" as a deliberate joke (Though it would be a most spectacularly ironic typo if it weren't)

American spelling is, in many ways, simplified (Which could be seen as a good thing) - and far be it from me to take offence at jokes aimed at other nations.

 

[levi]

I'm not sure why we need both 'upstream sources' and 'upstream website'. Normally, the website, being a URL is the upstream source.

I guess also the 'Forum' url is designed to link to the actual forum thread, not that SoRR for Pyra has a thread yet.

I'm also a little confused by the license 'type'. In this example it says 'Need-Data' to indicate that this package needs game data for the apps to run, but for ported games that include all assets, what should this be used for? I don't really see why this is in the license section at all to be honest.

I suspect in the future, once a license database has been designed and set up, all you need is the name of the license which can be looked up. As is, having three entries that need to be filled in right now seems excessive.

What does disabling an app in a specific package actually do? Does it alter the dbp file to disable it there, or does it just limit what's shown on the website. If the latter, I don't think that's a great idea; if you're shipping something in a dbp, the website should document that, no more and no less.

 

[trix]

Hello, I would just like to express my gratitude for the work you've done so far, and maybe make a humble request, if it's not too much trouble.

Would it be feasible in your project given your time and priorities to eventually make available a tool that can take a .deb package or an aptitude source and convert it to a DPB for use on removable media? Perhaps a way to use dpkg or apt to redirect the install to a temporary squashfs where it can be autoconverted to a DPB?

This way the insanely huge Debian repository is immediately available as a DPB and whether we install something to the OS itself (apt-get) or to removable media (DPB) is simply a choice.

I do understand there would be many packages that wouldn't work this way, especially with dependencies and all, but this way I could just grab a game like Xonotic, install the dependencies to the OS, and install the game itself to a DPB file to add to SD card. All without requiring someone to package it up for me and add it to a repo.

Just an idea.

- trix

 

[sebt3]

Just an idea.

The idea is realy nice. I just dont see how I can do this.
I havent produced any dbp yet, but i've done some pnd. Doing a pnd (and a dbp) is not a mere packaging task. There's control to adapt, screen resolution and many others things. These cannot be automated. And even if you want to go without all the adaptations, there's the prefix issue. Debian binaries are built with prefix=/usr. DBP require a distinct prefix (I cant remember it right now since I never built any dbp, but for pnd, it's /mnt/utmp/<packagename>). Changing the prefix (aka where the binary look for all its data) require rebuilding it.
Basically, you're looking for a rebuilding farm (something that apt-get source ... rebuild and repackage as dbp). It's a very interesting project but it's way too far from what i'm building here.
Cloudef's PUR project aim was exactly this for the pandora. As far as I know, he was basically the only user of his project...

 

[bzar]

Cloudef's PUR project aim was exactly this for the pandora. As far as I know, he was basically the only user of his project...

Hey, I've used it for PNDManager for quite some time

 

[sebt3]

Changes since last status report :

• Added debian packages support (link)
• Added apt support
• Added an initial support for dbp-get
• Make a dbp-get.sh script

Still todo :

• Fix the carroussel in tab bug
• Make a better app page (mockup welcome)
  
• Make a better package page (mockup welcome)
• improve apps list

To test all this, this is what I made (as root, this will probably end-up in the OS by default) :

wget -O - https://pyra-handheld.com/repo/dists/community/apt-key|apt-key add -
echo "deb [arch=armhf] http://pyra-handheld.com/repo/ community main contrib non-free">/etc/apt/sources.list.d/multistrap-community.list
apt update
apt install dbp-getsh​

Then as a user :

dbp-get.sh install ptitSeb_ht​

And I could play Hostile Takeover

 

[Linux-SWAT]

Nice. Thanks for the hard work.

 

[levi]

Ah so this isn't an update to take a debian .deb file and make a .dbp file out of it (which admittedly would be very difficult), this is a new debian repo that currently just holds a package which gives you a script that can pull .dbp files from the dbp repo. Worth having definitely, but I thought we were already going to have a pyra-specific .deb repo on top of the debian repos.

Maybe, if that hasn't been set up yet, this could be that .deb repo. How would other devs get access to it to submit e.g. packages to control the LEDs?

 

[sebt3]

Ah so this isn't an update to take a debian .deb file and make a .dbp file out of it (which admittedly would be very difficult), this is a new debian repo that currently just holds a package which gives you a script that can pull .dbp files from the dbp repo. Worth having definitely,

you got it and, as I said earlier, I don't plan on making a build farm so I wont do a deb to dbp converter.

but I thought we were already going to have a pyra-specific .deb repo on top of the debian repos.
Maybe, if that hasn't been set up yet, this could be that .deb repo. How would other devs get access to it to submit e.g. packages to control the LEDs?

Yes there's an official repo (http://packages.pyra-handheld.com/debian) but as it's official, it may be a bit complex to get your package in for anyone. And certainly, for some package, it wouldnt make any sense.
This is a community debian repo. Anyone from these boards can upload their packages there without any hassle. I dont see this happen a lot, and I dont plan on making this anything other than a side feature.
I have a project that doesnt realy belong to a dbp package yet dont make any sense in the official repo. I could have setup a stand-alone deb repo for me (since ED provide me a webspace) but this is for everyone.

The point here was to make it something more than just an ugly website but a community tools for everyone.

 

[ptitSeb]

I tried, but "apt install dbp-getsh" didn't work at first.. "apt-get install dbp-getsh" did work, so it probably was some cache issue somewhere...

Nice script, with update and list capabilties

 

[Swordfish II]

I tried, but "apt install dbp-getsh" didn't work at first.. "apt-get install dbp-getsh" did work, so it probably was some cache issue somewhere...

Nice script, with update and list capabilties

I still use apt-get.... Old habits

 

[sebt3]

Changes since last status report :

• Update the apps list based on feedback (more suggestion welcome)
• Updated the app page based on feedback (more suggestion welcome)
• Added the ability to add description the a package version to build a changelog
• build a new screenshot widget
• Fix the modal appearance bugs

EDIT: fixed the modal bug

 

[Linux-SWAT]

Updated french translation.
The english part has problems, but I guess it's a native speaker who should correct that.