The software side

[vinipsmaker]

Here you go :

I'm guessing that this is the procedure to fix a broken system, because I don't want to go over it everytime I want to install a package.


And before you say:

But you can install online to get things "for free"

I can tell that this system only works online.

1*) On the offline PC:


sudo apt-offline set libabc-offline.sig --install-packages libabc


2*) On the online PC: (there is a windows binary available too)


sudo apt-offline get libabc-offline.sig --no-checksum --bundle libabc-offline.zip


3*) On the offline PC:


sudo apt-offline install /media/USB/abuse-offline.zip


Also work with update/upgrade and such...

I took a bit of time to reply because I wanted to confirm my concerns of your solution. So here it goes:


Your system maintains a local copy of the list of packages that exist in the remote server. That's how apt-offline work. When you generate the "offline list", you generate direct references to packages and versions. e.g.:


http://http.debian.net/debian/pool/main/libe/libevent/libevent-2.0.5_2.0.19-stable-3_i386.deb


So, the offline system may be old and the mentioned version may not even exist on the remote server anymore.


Current PND system works and you're trying to replace it with something that will work only for most of cases, but will fail badly on the remaining.

With all your arrogance, what system do you offer that work up to *your* standard ? If this doesnt fit

My standard is higher than what I'm proposing. Let's focus on what is good for everyone first and then I can provide some patches that will probably benefit only me and one or two users later.

 

[vinipsmaker]

If a library breaks compatibility, it should change its major version number. If my application depends on SDL 1.2, and another one depends on SDL 2.0, then there is no problem. The upgrade to SDL 2.0 will not remove SDL 1.2. An update to SDL 2.0.1 will not break anything, and whatever improvement the update makes, it will be there for everything that uses SDL 2, immediately. What is the problem?

Is this that kind of argument where I only need to show one counter-example? Wonderful, here it is:

https://aur.archlinux.org/packages/ps/psx/PKGBUILD (look for libpng14)

And in theory I agree with you. This is how serious libraries should be done. My own library uses this convention.

You can argue that games don't really have dependencies and that PNDs only need to be used for games, but I'm not so sure about that. FIrst of all, I think games can have dependencies, and serious ones too, especially FOSS ones. E.g. games that use Python or Lua or whatever -- do you really want to put all of that inside the PNDs or fix in advance what is available and what is not? Also I think the PND system can also be nice for non-gaming big software, e.g. geographical stuff (GPS maps etc), scientific software with big data sets, and so on.

Use .deb and be happy.

 

[_wb_]

 

You can argue that games don't really have dependencies and that PNDs only need to be used for games, but I'm not so sure about that. FIrst of all, I think games can have dependencies, and serious ones too, especially FOSS ones. E.g. games that use Python or Lua or whatever -- do you really want to put all of that inside the PNDs or fix in advance what is available and what is not? Also I think the PND system can also be nice for non-gaming big software, e.g. geographical stuff (GPS maps etc), scientific software with big data sets, and so on.

Use .deb and be happy.

Ugh.

Let me give an example. Say I want to make a navigation application that depends on some GPS library and some version of Qt and ImageMagick and svg and a whole lot of such things, and it comes with 5 GB worth of maps and other data, then I have two options:

• either ship it as a .pnd with all dependencies included, forcing people to update everything each time one of the dependencies are updated
• or ship it as a .deb and "be happy", forcing people to sacrifice 5GB of their internal storage on my application.

Neither of those options sounds good to me. I could of course apply some trick like shipping the data separately from the rest, shipping it as a .deb that installs the program itself to /usr and the data to an SD card.

 

[vinipsmaker]

Let me give an example. Say I want to make a navigation application that depends on some GPS library and some version of Qt and ImageMagick and svg and a whole lot of such things, and it comes with 5 GB worth of maps and other data, then I have two options:

Oh, I see. You argue a good point. Thanks.

Now, your solution brings other problems that I want to avoid. What do you think about a tool to create delta-packages? I can develop one.

 

[sebt3]

I took a bit of time to reply because I wanted to confirm my concerns of your solution. So here it goes:

Your system maintains a local copy of the list of packages that exist in the remote server. That's how apt-offline work. When you generate the "offline list", you generate direct references to packages and versions. e.g.:

http://http.debian.net/debian/pool/main/libe/libevent/libevent-2.0.5_2.0.19-stable-3_i386.deb

So, the offline system may be old and the mentioned version may not even exist on the remote server anymore.

And you failed in your research.The 1st step put the request and package status in a tarball.

On the online host, apt-offline will read that request and package status, put an updated repository definition in an other tarball then include all the .deb files requiered to do the install. In your previous example the final tarball would include an updated firefox.

Finally, apt-offline on the pyra would update (as in apt-get update), then install all the deb using apt cleanly. No breakage. No mess. Debian have been very conservative on this since the very beginning...

Note that the pyra is a handheld system. So even if you cannot connect it to the local wifi for some reason but can on a PC, there is no actual moving between place like it was when this solution was setup. apt-offline had to be reliable enough to not force someone drive 50km 2 ways because it missed a dreaded deps'...

Current PND system works and you're trying to replace it with something that will work only for most of cases, but will fail badly on the remaining.

Who said I want to replace PND with deb ? I'm all for pnd support on pyra. It should come without saying...

 

[vinipsmaker]

And you failed in your research.

The 1st step put the request and package status in a tarball.

On the online host, apt-offline will read that request and package status, put an updated repository definition in an other tarball then include all the .deb files requiered to do the install. In your previous example the final tarball would include an updated firefox. Finally, apt-offline on the pyra would update (as in apt-get update), then install all the deb using apt cleanly. No breakage. No mess. Debian have been very conservative on this since the very beginning...

I see. Problem solved.

But it also means that there is no "include .deb files together with the .pnds" (it would be specific to each device). You need at least two passes among the two systems. This installation procedure will force user to connect to the internet or have a painful process (it can be easier with automated scripts, but no so easy as what we have now).

Anyway, now I can agree that this is an option.

Moving on, what option will we choose?

 

[Linux-SWAT]

Slackware.

 

[sebt3]

what option will we choose?

by the look of it, that "we" will be a few souls that will rush a solution at some point. Then it will be what ever they know the most to deliver the fastest... 

 

[Askarus]

May I just add an other feature I'd like to have:

If I have the deadbeef PND on my SD I want to type deadbeef in the terminal and launch it.

 

[vinipsmaker]

May I just add an other feature I'd like to have:

If I have the deadbeef PND on my SD I want to type deadbeef in the terminal and launch it.

This is easy. Added to the table: http://pandorawiki.org/New_PND_format#The_2014.2FPyra_effort

 

[Neelix]

 

You can argue that games don't really have dependencies and that PNDs only need to be used for games, but I'm not so sure about that. FIrst of all, I think games can have dependencies, and serious ones too, especially FOSS ones. E.g. games that use Python or Lua or whatever -- do you really want to put all of that inside the PNDs or fix in advance what is available and what is not? Also I think the PND system can also be nice for non-gaming big software, e.g. geographical stuff (GPS maps etc), scientific software with big data sets, and so on.

Use .deb and be happy.

Ugh.

Let me give an example. Say I want to make a navigation application that depends on some GPS library and some version of Qt and ImageMagick and svg and a whole lot of such things, and it comes with 5 GB worth of maps and other data, then I have two options:

• either ship it as a .pnd with all dependencies included, forcing people to update everything each time one of the dependencies are updated
• or ship it as a .deb and "be happy", forcing people to sacrifice 5GB of their internal storage on my application.

Neither of those options sounds good to me. I could of course apply some trick like shipping the data separately from the rest, shipping it as a .deb that installs the program itself to /usr and the data to an SD card.

What I don't quite get is why you seem to see these issues as insurmountable.   I've no doubt there's a good solution for most of the issues raised it's just a matter of finding it.

How about this:  The PND includes .deb files for it's dependencies.   If they are already installed it uses the installed version.  If they aren't installed it prompts to install them.  


That way,  the PND includes all the files it needs,  but will still use the up to date versions of the dependencies if they exist and are installed.

- Neelix

 

[_wb_]

That would work, but it would make PNDs quite a bit larger than needed, and as soon as the dependencies are installed, it's just dead weight.

I understand the appeal of fully self-contained "game cartridges", but I also don't want to waste space and bandwidth. Forcing everyone to download and store redundant (and probably old) versions of the dependencies (either by including them directly in the PND or by including them as failsafe .deb files somehow attached to the PND), that doesn't sound good to me.

Maybe a better solution is to store a .deb cache on the SD card of the PND that caused the .deb files to be downloaded and installed (in a folder called, say, pandora/dependency_cache). You are free to clean up this cache, it's not needed anymore when the .deb's are installed. If you keep it around though, it makes your SD card with PNDs self-contained, since even if you reset your base system to the default (or use the SD card on another Pyra unit), the cache can be used instead of downloading the .debs (in case there is no network or the cached .debs are still up to date).

 

[Neelix]

I really dislike the idea of downloading and installing a PND only to have to  download a bunch of deps on first run.  Starting a program that doesn't involve networking should not require an internet connection. 

Given that we have a process for building PNDs from a recipe though it doesn't seem unreasonable to build two versions,  one that includes all necessary deps, and one that just lists them in metadata.   Then offer the user a choice (and a way to view the list of deps) before downloading.

- Neelix

 

[EvilDragon]

Well, at one time, you need to get the PND, right?

That's when you've got internet access.

If PNDManager would check for the dependencies and which ones are already installed and which not, it could tell the user the total size to download and automatically handle this (via normal apt)

When using a PC with the repo, the repo could send you the PND and a file including all the dependencies. You copy both onto the SD Card. On first run, the daemon that starts the PND would install the dependencies - via apt-offline.

Those could then safely be deleted afterwards.

And if the user runs a PND where not all dependencies are installed, the daemon could offer to download and install them right on the Pyra, in case the user has not copied the dependencies onto the card.

What about that?

 

[Linux-SWAT]

That's evil !

 

[vinipsmaker]

How about this:  The PND includes .deb files for it's dependencies.

Read the topic. This is not a solution. Only solution is apt-offline, which will work as easy as it can (within a dependency system).

When using a PC with the repo, the repo could send you the PND and a file including all the dependencies. You copy both onto the SD Card. On first run, the daemon that starts the PND would install the dependencies - via apt-offline.

Possibly there will be a second pass (or third) to make apt-offline work (but it'll be as little as possible). It's not that user-friendly. Just ship the .debs is to rely on lucky, but we're not doing that.

After Cloudef publishes his makepnd tool I'll try to tune it to support online and offline PNDs. Let's leave the choice for the user.

 

[bzar]

If PNDManager would check for the dependencies and which ones are already installed and which not, it could tell the user the total size to download and automatically handle this (via normal apt)

PNDManager's gonna need more devs

 

[pmprog]

Well, at one time, you need to get the PND, right? That's when you've got internet access

Yes, but not necessarily on the Pyra. People do download on desktops then copy to SD cards.

 

[vinipsmaker]

Well, at one time, you need to get the PND, right? That's when you've got internet access

Yes, but not necessarily on the Pyra

Hey, don't start the flame war again. Just say if you agree with the most recent solution and, if not... tell why.

 

[_jr_]

And as someone already said, turning PND-Manager into yet another dependency management tool is just reinventing the wheel.


We need a PND like system to reasonably use removable media as storage for applications themselves (and not only data), because the OS simply doesn't cut it (and it can't unless it puts up Amiga style 'insert volume xxxxxx: into any drive' requesters or something like that).


With little ressources it is best to not set the goals too high and just keep these ('system package management' and 'apps') as seperate as possible. Which has downsides, I totally agree. But even if the current system has been hacked together, it is really not that bad. I'd be surprised if we manage to put together something significantly better (the original creators were not stupid and pretty experienced already).


A simplified version of _wb_'s proposal could look like this:


- we have a base system with a package management tool


- we have application bundles I'll call for this argument 'PND's


- when the future PND-run starts a PND it interprets a 'base-system' field (or several) of the PND descriptor as the name of a package and just checks whether the package is installed and produces a warning if it isn't.


This way you could produce a package that depends on KDE services to launch a browser or PDF viewer by just adding something like 'KDE' to the PND and if you have KDE installed everything works out of the box and if you haven't you are out of luck. It might run anyway, but some features probably won't work. If feasible there could be a larger PND containing everything required for users not wanting to run KDE (e.g myself


This is a bit like the current PNDs that require Java, only more explicit. I'd argue it is better not running a PND than installing e.g. Java behind the users back. Repo support for filtering the requirements would be a nice bonus (e.g. PNDManager having the option to only show the packages fitting the current system), but the amount of work required to pull this off still seems quite limited. All the components are already there.