Thoughts about an DBP Manager


lukey

Rare Species
Joined
Jun 17, 2015
Messages
504
Location
Germany
Hello,
I've been thinking about an DBP Manager for the Pyra recently and here are some features, that an DBP Manager could/should be able to do:
  • Managing of DBP's and DEB's (and maybe even PND's, if there's an compatibility Layer) at the same time
    • DBP packages replace/overwrite DEB packages in the Package list (as they are more Optimized) (DBP Maintainer specifies, which DEB package)
      • "Link" to the DEB Package on the DBP "Page"
    • The whole System can be Updated through the DBP Manager.
  • Multiple User/Maintainer-shareable appdata tar's or Patches: For Example someone makes an Optimized Build of Libreoffice, but it only supports English or None Spell Checking, then the Maintainer or any User could add additional Language Plugins to LO which get saved into the Appdata Folder which the User/Maintainer then can Upload separately. So there could be an Appdata tar for English Spell Checking, for German Spell Checking and so on. This way, Emulator Settings and other things could be easily shared too.
    • Maybe even Multiple Appdata directories?
  • DBP Updates via Binary-Diff's?
  • Change-logs separate from Package Description
  • DBP Dependency resolving (For example for an Java DBP)
    • Resolving between DBP/DEB? For Example an DEB Package depends on Java. This Package can then use the (Optimized) Java DBP.
      • Or the Other Way around: DBPs can use the Optimized DEB Packages from our custom DEB Repo
  • Cli and GUI interface.
  • Moderator approval of DBP Packages to make sure that they don't contain Malware/Viruses.

Maybe I'll hack something together with tcl/tk.
 
Last edited:
This way, Emulator Settings and other things could be easily shared too.

I like that.
Do you know how the Steam controller works?
Everyone can upload and share his/her controller setup for games. Other users can download and rate this.

Would be nice to also have such a config repo for games and programs.
Let's take all the 3D FPS Games. I've made a (pretty good) config for Jedi Knight but others might refer an other setting. A repo for such things would be great.
Mupen 64 is also a great example. Which Plugin does match best for which game? A database with game specific settings would be great.

Means less work for the maintainer and if it's easy to contribute great experience for everyone.

DBP packages replace/overwrite DEB packages in the Package list (as they are more Optimized) (DBP Maintainer specifies, which DEB package)

Don't like that.
What if a DAP is outdated and a DEB is more recent?
What if the more recent DEB works better?
What if the more recent DEB does not work?
What is the old DBP is still better due to optimizations than the more recent DEB?

I would prefer to have 2 versions. DBP and DEB. With an explanation why the DBP does exist and what it dies better.
I would not want to overwrite the DEB.
 
Debian packages should work in general and it shouldn't be a problem to have an automated process which rebuilds the DBP package each time the repo is updated.
 
Yeah, I don't see any need to integrate DEBs and DBPs. DEB packages exist for when you want to install something to internal flash and always have it with you. DBPs are more portable, and designed to live on SD cards that can be mounted and unmounted at will. DEBs already have a perfectly good management system - apt-get or aptitude or various GUI tools.

There might be overlap between the two, but if a user chooses to remove the firefox DEB after downloading a firefox DBP, then that's up to them. Having two independent managers mean users have to manage the overlap, but that's overlap they create themselves by downloading things, so I think that's okay personally.
 
There might be overlap between the two, but if a user chooses to remove the firefox DEB after downloading a firefox DBP, then that's up to them. Having two independent managers mean users have to manage the overlap, but that's overlap they create themselves by downloading things, so I think that's okay personally.

Absolutely.
With a proper hint in the DBP manager everything will be fine.

The worst thing that can happen to the user is that a program will appear twice in the menu.
Maybe the DBP manager could display a warning message when it detects a DEB version of the same package already installed.
Or simply an icon: "DEB already installed"
 
O.k. then there will be an "Link" to the DEB Package on the DBP "Page". I think its handy to have Both Package Formats in one Manager especially if you search for an App.
Maybe we should put optimized version of some common dependencies on the Pyra DEB repo (Where the Kernel will also reside?).
Also screw tk as the List element is way too limited and it looks Old (yeah. I only looked at the GUI so far). Maybe we should just modify Synaptic? Or PND Manager? (As I like the modern Look of it)
 
Last edited:
Could PackageKit be useful here? With an appropriate command line based DBP manager and matching PackageKit backend, perhaps you could modify one of the existing PackageKit front ends to handle both systems in one interface.

Just a thought. (I have no idea of it's practicality)

-Neelix
 
Using packagekit as an abstraction layer to not tie ourselves into Debian's dpkg system and make the solution more portable might have some benefits, but I didn't get the impression that it's designed to support two packaging systems at the same time, so I don't expect you'll get much benefit by making packagekit aware of dbp files. That's based on a quick scan of the docs only, admittedly.
 
What is wrong tcl/tk?
That's what I'd like to know! I don't see anything wrong with it.

Ok, ok! Didn't realize I had stumbled into a patch of tcl/tk programmers.

I really didn't thing the thread was serious. It really seems odd to try to mix an extra packaging system on top of/beside Debian. What's wrong with working with Debian on new packages?
 
Well I was kind of joking about tcl/tk, mostly because I still deal with it at work...

It really seems odd to try to mix an extra packaging system on top of/beside Debian.
It's mainly because of the nature of removable media, Sure it is less of an issue than the Pandora with a very limited internal Storage and the Pyra in comparison has quite a bit, but still not as much as most people are used to. The idea of the DBP and the PND that came before it is to have self contained packages, ones you can copy to the SD card and not worry about removing the SD card and breaking a bunch of dependencies and what not. Just download and run essentially, You can move applications and application data to one SD Card to another with breaking paths and what not. debian packages are fine for the base OS, but 32GB the pyra will have can fill fast if installing games with large amounts of game data and if you're forced to keep an SD card mounted it kinds of eliminates some convenience.

The PND system works well, but it had some drawbacks in ease of building and some clunky nature in how they worked. The DBP what I've tried in early builds is really promising, and takes what was good with the PND system and improves upon it.
 
Back
Top