A possible PND-system replacement

[levi]

I know .PND has a nice ring to it but .DBP makes a lot more sense and we can differentiate between old and new.

Purely familiarity though I suspect.  'DBP' probably sounds better to me because it's three mouth voiced sounds with the same end mouth shape: 'dee bee pee'.  In comparison, 'PND' benefits from sounding like 'P and D' spoken colloquially, but not much else, with most of the work being done by the tongue for the 'N'.  'DBP' should be easier for mouth readers, as the mouth closes for each syllable.

I'm personally against anything referring to Pyra, since the intention of this is for it to be a portable packaging system for removable media.  Conveniently, while the P in DBP refers to package, we usually refer to 'PND files' rather than 'PND packages', so we probably will call them 'DBP files' not 'DBP packages' and double up on the packages.

 

[_wb_]

Yes, ".de" probably looks too much like the German TLD.

Anything with "DB" in it makes me think of something database-related though, so I don't really like ".dbp". But I also agree that a specific reference to Pyra is not a good idea. Then again, a specific reference to DragonBox may not be a good idea for the same reason: it could be a portable packaging system for removable media for non-DragonBox hardware too.

What about ".dpegg"? It could be a Dragonbox Pyra Egg, but also a device-neutral DPEGG Portable Encapsulated Great Gift or whatever recursive backronym you can invent. Other options could be ".degg" (Dragon Egg) or ".pegg" (Pyra Egg).

Maybe it's the Easter thing, but I kind of like the word "egg".

 

[KickAss]

Maybe it's the Easter thing, but I kind of like the word "egg".

yes, we couldnt help but to notice that

 

[TrashyMG]

DragonBox Package (DBP) seems fairly straight forward.

 

[thatgui]

Maybe it's the Easter thing, but I kind of like the word "egg".

I like the analogy

DragonBox Package (DBP) seems fairly straight forward.

C'mon this is the Pandora board we always strive to broaden our horizon, even if that means getting onto a whole new level of "silliness" regarding discussions

Ontopic:

@ slaeshjag

• Is there support for description and screenshots ?
• With a pnd I have the possibility to "overwrite" some metadata by leaving a file with the same name (can't remember anymore wether it also had an extension) in the pnds directory. Does your system have a similar mechanism ? And if so, what options does it provide ? If not, are you interested in implenting it ? If so, feature request from my side, would be to have the possibility to "overwrite" name and category and (for multi application dbps) the ability to hide certain applications.

 

[slaeshjag]

Support for screenshots and descriptions are not standardized yet. Since nobody has really held a conversation about it, I am for now going to suggest that screenshots are placed inside the meta-zip in a folder called preview/, shown in order per binary sort of the file names. Suggested file formats are png (preffered) and jpg (for those screenshots that doesn't look shit with it, I'd say jpeg is acceptable if it makes a huge difference in file formats.)

For a longer description, I suggest a description/ folder inside the meta-zip, with one file per language/locale (for example, description/en_US, description/pt_BR)

No idea about formatting (markdown?)

The actual implementation of the two doesn't matter as long as we all agree on it, the system daemon doesn't care. But I'm a fan of implied data.

There's currently no support for overriding the launchers budled. I may implement it in the future. It will require some additional infrastructure though, to make it accessable to users. It will probably involve writing a separate .desktop that is merged with the package supplied one, with preceedance for the user supplied values.

 

[_wb_]

Sounds good. PNG is probably the best choice for most desktop applications (which have mostly text and gui widgets), while JPEG is probably best for games. Since most desktop applications will not be put in dragon eggs but rather be already available as Debian packages, I don't see a reason to explictly say that PNG would be the preferred screenshot format.

For the description: maybe just use HTML? Or rather a subset of it, with just some simple tags like <b>, <i>, <p>, <ul> etc. Basically something that could just be pasted verbatim inside a <div> on a web page, to be styled in whatever way using CSS. That would probably keep it easy to write the repo website software.

 

[Neelix]

Sounds good. PNG is probably the best choice for most desktop applications (which have mostly text and gui widgets), while JPEG is probably best for games. Since most desktop applications will not be put in dragon eggs but rather be already available as Debian packages, I don't see a reason to explictly say that PNG would be the preferred screenshot format.

Until something is officially chosen can we stick with calling them DBP files? Referring to them as a dragon eggs seems... off somehow... *shrugs*

That aside, I would hope that most desktop applications are available in both formats, as while there are one or two I'd like to have installed as Debian packages most I would still want as DBPs so they can be installed to a SD card.

Perhaps Cloudef's MakePnd could be adapted for that?

- Neelix

 

[_wb_]

That aside, I would hope that most desktop applications are available in both formats, as while there are one or two I'd like to have installed as Debian packages most I would still want as DBPs so they can be installed to a SD card.


Perhaps Cloudef's MakePnd could be adapted for that?

Right, OK. But I guess it's less important to have our own metadata for those, since they will already have metadata in the Debian repositories. Ideally, there would be something like "apt-get install_as_dbp <packagename> <path_to_sd_card>", which somehow automagically repackages the Debian package as a portable DBP file -- and for all missing dependencies it would ask you whether you want to install them globally on your root filesystem, or whether to include them in the DBP file.

I imagine that the Pyra repo would not include such autogenerated DBP files though, but only Pyra-specific stuff.

 

[slaeshjag]

^ There's a major problem with autogenerating dbp packages from debian packages.

Most software is build with hard-coded paths.

 

[Neelix]

IIRC MakePND is designed to build both debian and PND packages from source. It would mean we could build customised versions of software and put them into both a DBP repo and a regular deb repo to be used with apt-get. We could add both Pyra specific and standard Debian repos to the repo list with the Pyra one pinned to take precedence for the the customised builds.

- Neelix

 

[Cloudef]

The makepnd is simply fork of the arch's makepkg, which is quite flexible to modify to support any sort of package format, and I doubt I'm only one who has done this.

I would not use it for packaging distro / system packages, but it is good for 3rdparty or sandboxed packages such as pnd, or building for the pandora's os where packaging is pita.

That said, debian's packaging model is also sort of akward.

You can browse the user created recipes here: http://pur.cloudef.pw/recipes some of them are almost identical to arch variants.

 

[_wb_]

^ There's a major problem with autogenerating dbp packages from debian packages.

Most software is build with hard-coded paths.

Sure. But can't we do something like make /usr a unionfs on which the .dbp debian packages get overlaid?

 

[sebt3]

Sure. But can't we do something like make /usr a unionfs on which the .dbp debian packages get overlaid?

that would disallow more than 1 dbp run concurently...

 

[Christoph.Krn]

I have a couple of ideas about the metadata which have been brewing somewhere in the back of my head from some other stuff that I've been doing, I'll just list them here and you tell me what you think.

Title header - A ~half-a-sentence long mini-summary of the description

Comprehensive descriptions are nice and all, but when you're confronted with a wall of software (as can be the case in a repository), this kind of description isn't very effective at helping you figure out which items might match your personal interests. This could be changed with a more progressive approach, with different levels of descriptions: The more "entry" level, the less thorough (and vice versa).

Examples (I've additionally added category and subcategory information to these examples, to demonstrate that it can be okay for a super-distilled description to not make sense on its own):

TITLE HEADER
TITLE
(CATEGORIES - SUBCATEGORIES)

Use your screen as a flashlight with
Pandora Flashlignt
(Utility)

Dynamic enemy path tower-defense RTS
Pandora Microbes
(Game - StrategyGame)

Indescribable double-nub creature attraction action
Pandora NubNub!
(Game - ArcadeGame)

Plaintext-based solid 3D CAD object creator
OpenSCAD
(Development)

Shanghai clone
Lopan
(Game)

Desktop application launcher
Warlock Bar
(Utility)
Escape path key - Which button reliably gets one out of the software?

...and...

Menu buttons - Which gaming buttons navigate the menu?

(...think fullscreen software such as games)

"Escape path key" is the key which, after a single or a repeated pushing, would eventually put users in a situation where it's very obvious how to exit the software. The general idea is that this key would allow users to "traverse back". For example, in a game it could go to the pause menu, then to the main menu, then an exit prompt (or so). You get the idea, the "Escape Path key" keeps users from getting "stuck" somewhere. Everything else, the exact path that the user takes through the user interface and software states, would be up to the developer.

"Menu buttons" is essentially a representation of whether a software supports flipping the ( B) and (X) buttons' meanings in menus, and if it doesn't, it should allow specifying the two buttons/keys which are instead used for navigating back/forth in the software's menus.

-----

That's it, for now at least.

Have there been any further developments about the description format in the meantime?

 

[_wb_]

Sure. But can't we do something like make /usr a unionfs on which the .dbp debian packages get overlaid?

that would disallow more than 1 dbp run concurently...

Aren't there implementations of union mount that allow more than just two overlays? We only need read-only overlays as far as /usr is concerned, so I see no a priori reason why overlaying should be very tricky.

 

[levi]

Regarding usr, I'm probably naive but I'd have though you could get quite far by setting PATH and LD_LIBRARY_PATH judiciously.  /etc, /var and /home are going to need other solutions though.

 

[sswam]

Did anyone suggest ".box"? It seems like a reference to Dragonbox, but in fact it isn't.

 

[thatgui]

@slaeshjag

In the past the idea was thrown around to minimze datatransfer by just transferring the file differences - any (non) interest in providing something like that in the dbp system ?

Edit: this refers to updates of dbp files

 

[slaeshjag]

^ It would be quite difficult to achieve that using squashfs compressed filesystem images, so I'm afraid it will not be any more feasable than it was for the PND system.

...I guess you could potentially download additional squashfs images that contain the updated files and have them override the earlier ones, but that would make a mess of your SD card...