deb packages still in focus


yeoldegrove

yeoldegrove

Member
Joined
Mar 9, 2011
Messages
54
Location
Germany
I just skipped through this DBP thread (not in depth) and saw a lot of issues coming up e.g. detecting collusions with other packages or dependencies.,,
Why not use the well documented and functioning deb package system?
I'm not an expert on the deb topic, but I think building deb-packages in an build environment like OBS (open suse build service) would be a great Idea.

- We would have a system (even a great GUI) accessible for all developers to build deb packages!

- All source code would be available and in revision control.

- Everybody could commit fixes (and UPDATES!) for packages directelly to the developer (processes for this are included in OBS). If a developer doesn't have the time anymore to keep up with development, somebody else can take over...
 
yeoldegrove said:
I just skipped through this DBP thread (not in depth) and saw a lot of issues coming up e.g. detecting collusions with other packages or dependencies.,,
Why not use the well documented and functioning deb package system?
I'm not an expert on the deb topic, but I think building deb-packages in an build environment like OBS (open suse build service) would be a great Idea.

- We would have a system (even a great GUI) accessible for all developers to build deb packages!

- All source code would be available and in revision control.

- Everybody could commit fixes (and UPDATES!) for packages directelly to the developer (processes for this are included in OBS). If a developer doesn't have the time anymore to keep up with development, somebody else can take over...
Click to expand...

We still have the issue where removable storage will be most likely still be the main storage solution for applications as eMMC storage size may be only large enough to install a handful of programs on top of the OS. We need a solution that works with SD cards being swapped out and such. DBP packaging isn't as big of a deal as PND making on the pandora.


EDIT1: Debian packages still could be made and maintained like you said, we already have a debian repo for official Pyra specific things, perhaps a community repo could be started. A deb to dbp package tool could very likely be developed too if slaeshjag hasn't already made one.
 
Last edited:
TrashyMG said:
we already have a debian repo for official Pyra specific things, perhaps a community repo could be started
Click to expand...
Could you give me the url (if it's public)? I have a bit of spare time next week and could look into building your stuff in OBS.
I haven't build deb packages in it yet, but would look into it.
 
The only problem with deb packages is that they're likely not compiled with optimisations for the Pyra (Neon Float and specific GCC optimisations), this is pretty likely why dosbox suffers for anything intensive when building from apt (Which is likely missing the thumb-interwork and dynamic recompiler options for ARM)

You can install debs using dpkg fine.
 
Wally said:
The only problem with deb packages is that they're likely not compiled with optimisations for the Pyra (Neon Float and specific GCC optimisations), this is pretty likely why dosbox suffers for anything intensive when building from apt (Which is likely missing the thumb-interwork and dynamic recompiler options for ARM)

You can install debs using dpkg fine.
Click to expand...
Well, not the only problem. The other, bigger one is working with removable media, as already pointed out.
 
Wally said:
The only problem with deb packages is that they're likely not compiled with optimisations for the Pyra (Neon Float and specific GCC optimisations)
Click to expand...
I think not everyone gets the point here... With OBS you write your own specfiles (rpm or deb). In these files you can specify all compiler options you like, eg. neon optimized stuff rsulting in optimized deb files.

If the way a DBP is generated is published or even an automatic way to convert deb files is present this would be the best solution. A user then could even choose wether to install it the native deb way or install it as a portable DBP package.

To get to know OBS, take a look at build.opensuse.org.
 
Overlays + debs wouldn't really work with .debs for the simple reason that dpkg isn't designed to handle dependencies coming and going on their own accord.

Just plain overlays might stand a somewhat better chance at working. However, this will need special care taken to prevent things from entering /usr/sbin or /usr/local/sbin and the likes. Unclean umounts could be even more problematic. A lot of packages could also exhaust the maximum number of loop devices allowed (256), meaning no more than 256 packages can be present on a system at any time.
 
Last edited:
Let's say I want to install some DEB which happens to have a ton of dependencies. And I don't want to install it to eMMC due to space usage or to keep root fs clean.

Can't I create an overlay over the root fs, which redirects all modifications to a dir on SD card (assuming ext fs formatted SD card)? If so DEBs could be installed without the downside of filling up the eMMC.
 
Yes, you could presumably have one overlay into which you install all your extra deb packages, but that means all the packages are in that one overlay. Using the package manager you can still install and uninstall them, but some people prefer to eject their SD cards and manage them on their PC (at least when they're using their Pandora). The alternative is one overlay per package, but then you're limited by the system to 256 overlays.

That ejectability of the card is also a problem. You might be fine never ejecting your cards, but designing a system where you can't eject the card or you'll crash the system isn't exactly user friendly.
 
I think you misunderstand. I didn't mean booting the system running from the overlay (that's just crazy xD).

I meant setting up an overlay somewhere on SD card, chrooting into it and then installing java, for example. Can't I later safely unmount the overlay and eject the SD card?

I certainly won't be running persistent services (say SSH server) inside this overlay (then again, those would likely fit on the eMMC).

So if some DBP requires 100MB worth of DEBs to be installed to run, I could install those in an overlay on SD and then run the DBP on top of that. Ideally the overlay would only be mounted as long as the DBP is running.
 
Yes, you could do that. You'd have to beware of your package manager indexes though - you probably want to put those in your overlay, so they fall back to the version without all the packages you've just installed when you unmount the overlay. But say you later want a second overlay with video editing packages in, you could do the same, but you'd need to decide whether you also wanted java mounted at the same time - the package manager indexes would need to either know about everything including java and video editing, or just everything and video editing. As you build each overlay, you need to decide what state of other overlays you're building on, and once you've done that you can't install any other combination of overlays without breaking the package manager.

Having a broken package manager won't stop the system booting and running, mind you. But you'll have to make sure you don't apply any updates with the wrong package manager indexes installed, or it could start downloading gigabytes of data and filling up your overlay with packages from other overlays, or worse.

Edit: Also, imagine an overlay includes a library which is writing to a log file also in the overlay. The library is in memory when you unmount the overlay, and it tries writing the the log file. Best you can hope for is it writes to eMMC instead, but odds are it'll crash as the file handle becomes irrelevant half way through writing. And you can't always be 100% sure what libraries you're using at any given instant a lot of the time.
 
Keep in mind that dpkg keeps a central database of packages installed, and it lives somewhere in /var. If you don't keep it in sync with what's mounted, it'll assume installed packages are present regardless of if the overlay is active or not.
 
Also fun:
- Install application A that depends on library L when SD cards S1 and S2 are inserted. S2 contains L. S1 is the current "write" overlay. A is installed on S1, but L resides on S2. Replace S2 with S3. A is now missing a library the package manager claims is installed.
- Install package P1 on SD card S1. Install package P2 on SD card S2. P1 and P2 are conflicting packages. Insert both S1 and S2 at the same time. The system is now has conflicting packages.
- Install application A1 that depends on library L on SD card S1. Install application A2 that depends on library L on SD card S2. Perform package upgrade with S2 inserted. A2 and L are upgraded. Insert S1. Which version of L is in use? Do A1 and A2 both work? Only one?

There are just so many things that can go wrong here.
 
Maybe it's time thinking about a docker container for each package, so package can manage there own dependencies inside without side effects to any other package. In each docker image can exists a pxml file for integration into pyra menu. This needs more space, but with 32gb space and more it's not so serious. There are already existing docker implementation for CuBox-i Pro or others armhf devices.

Minimal docker size for debian is around 50mb.

Thomas
 
Last edited:
Nah lets just stick to .pnd/.dbp: If a package isn't already available as dbp, then you can still install the unoptimized deb package to eMMC and wait for the (optimized) Port to dbp. Also KISS
 
Yeah, it's funny how in resolving the problems with docker containers or manual overlays, we come up with pretty much the same requirements than the dbp project came from. Funny, that.
 
Ugh, you guys are just overcomplicating things. I want:
  • One overlay, install everything I want which can be safely installed in it. Packages which are not safe to keep in overlay would need to be installed to eMMC, of course.
  • Overlay is mounted as long as it is needed. Only when all applications which need the overlay are closed, is the overlay is unmounted.
  • No crazy "package on SD1 while dependencies on SD2". We don't keep the appdata dir on one SD card while the PND in other. May need one overlay per SD card, but that's OK I guess.
  • If the root FS is modified (say, firmware update) the overlays might need to be wiped out and rebuilt. Maybe a list of packages in the overlay could be kept to make rebuilding easier.
  • Maybe some kind of integration with DBP system. If dependencies are available on overlay but not on root FS then mount the overlay (if not mounted already) and run the package chrooted in the overlay.
 
Yoyobuae said:
No crazy "package on SD1 while dependencies on SD2". We don't keep the appdata dir on one SD card while the PND in other. May need one overlay per SD card, but that's OK I guess.
Click to expand...
Not intentionally, no. If you just use an overlay filesystem and regular dpkg to install stuff you may wind up with a situation like this quite easily though.

Install package P1 with dependency D with sd card S1 as the write overlay, insert SD card S2, install package P2 with the same dependency D, dpkg sees D as installed and doesn't install it on S2, remove S1, now you have P2 but no D.

Since dpkg has no idea you're doing this sort of overlay stuff it'll just quietly install the packages while the dependencies are physically elsewhere. Even worse, if the package index is on rootfs, you may have all the packages on any SD card marked as installed in it, causing dependencies not being installed on the overlay if they have ever been installed on any of your other overlay SD cards.

There are maybe some paths you can take to create a self-sufficient overlay on a removable media, but you need to be quite careful constructing it.
 
You must log in or register to reply here.

Similar threads

Tempel
distPND
Replies
15
Views
7K
myownlittlworld
myownlittlworld
Tempel
Pandora Distpnd
2
Replies
25
Views
6K
Esn
Esn
Farox
Pyra How to made a DBP for Pyra
Replies
7
Views
3K
sebt3
sebt3
jedi23
Pyra Unofficial Quick Reference
2
Replies
32
Views
12K
TeDaDeS
TeDaDeS
Ziz
Release Sparrow Compo4all Manager and Puzzletube C4A-Edition [Betas]
2
Replies
33
Views
5K
Ziz
Ziz
Back
Top