Opkg Manipulation

[chuckr]

I have a prejudice in the installation of packages which are outside of an OS'es core, that I like the core to center around "/", but I like extra stuff, like games, word processing, etc to fit into a /usr/local hierarchy. I picked this prejudice up from my BSD experience (they all seem to have that same prejudice, although they allow you to choose). I don't want to argue this, it's a personal bias, but I want to learn more about the opkg configuration file usage/location/format, so I can get it to work around a /usr/local base. It looks like I could definitely get this by adding a command line flag to every one of my opkg commands, but I would very much rather see if I could learn enough about the placing and format of opkg config files so that /usr/local would work, and just me forgetting to add in a flag wouldn't screw things up.

I'm aware that another way to do this would be to write a script wrapper around opkg, but I want to try, first, and see if I can get it to work via opkg's config. If opkg was better documented, I wouldn't bother this list, but I can't (using Google) find such documentation, so I need to see if such expertise exists here. Basically, I want to know where I would place such a config file so that it would work with /usr/local in my path, but opkg is currently installed in the "/" path, and I wouldn't change that (to me, opkg is part of the base). I also need to know how to write the config file in general, what a comment line looks like, and anythin g else that occurs to anyone, if something might be fatally wrong with my chosen method getting to /usr/local.

Remember, I have no intention at all of moving any of the base system, at all, it's only the optional stuff I want moved. That gives me a lot of flexibility that you can't have without a /usr/local. If anyone's tried this and knows of any problems I'll face that I might not see, I'd appreciate a heads-up. Being that I've been no part of the Op team for development, I'm not suggesting that anyone else consider doing this, it might be a fatal trick.

 

[Chero]

for things to work in /usr/local, they need to be compiled with that prefix.
Things in the angstrom feeds are not compiled like that.

There is a way, using the option "-d" (destdir) in opkg.
That way you can install things to another dir, all installed files are then symlinked to the corresponding places in /.
Your / will become full of symlinks to /usr/local.
Since / and /usr/local are on the same disk (I hope SD and not NAND) I don't really see the benefits.
You could however use this method to install things to SD and have them symlinked to NAND. Then I see the benefit. (opkg is smart enough to avoid installing system files to SD, the -d option is ignored sometimes)

You need to install "ipkg-utils" to be able to use this and this needs some manual copying because it's not available for armv7a (but the eabi version works fine)

opkg -d installs to the alternate location
ipkg-link creates the symlinks to /
/etc/opkg.conf can contains a line with the standard destdir, so no options are needed when installing.

I need to check how to configure ipkg-link to work. (I have tested it and it works - wrote about it in another thread - but now I'm running the base os from SD (4Gb partition) and "opkg install" - "opkg remove" works just fine for me.

Have fun,
Chero.

 

[chuckr]

for things to work in /usr/local, they need to be compiled with that prefix.
Things in the angstrom feeds are not compiled like that.

There is a way, using the option "-d" (destdir) in opkg.
That way you can install things to another dir, all installed files are then symlinked to the corresponding places in /.
Your / will become full of symlinks to /usr/local.
Since / and /usr/local are on the same disk (I hope SD and not NAND) I don't really see the benefits.
You could however use this method to install things to SD and have them symlinked to NAND. Then I see the benefit. (opkg is smart enough to avoid installing system files to SD, the -d option is ignored sometimes)

You need to install "ipkg-utils" to be able to use this and this needs some manual copying because it's not available for armv7a (but the eabi version works fine)

opkg -d installs to the alternate location
ipkg-link creates the symlinks to /
/etc/opkg.conf can contains a line with the standard destdir, so no options are needed when installing.

I need to check how to configure ipkg-link to work. (I have tested it and it works - wrote about it in another thread - but now I'm running the base os from SD (4Gb partition) and "opkg install" - "opkg remove" works just fine for me.

I appreciate the comments, even though the fact that binaries are distributed instead of built from patched sources, I noticed it, but it didn't really sink in, I'm too darned used to FreeBSD ports ... although even there, in the last few years, there's been a political feeling that folks install packages, not build ports. In fact, for OpenBSD, they get actively upset at you when you complain that their ports don't compile. I guess I will have to rely on cross-compiling, it'd be tyhe only way to build big things (like gcc itself) without Pandoras smaller limits getting in the way.. HOWEVER, let me back you up and even though I can't use the info for what I intended, I want to know where the opkg config file(s) is/are kept, and give me 2 or 3 representative lines from it, so I can see the format. I know you gave me the flags to use, but not how they'd look in the config file.

But, maybe I'll get my /usr/local via my cross-compiling and being excessively stubborn.

Oh, I want to drop another word about getting someone who was in on the Pandora's design to write up a user manual description of what EVERY key, every control on the Pandora does. A list of keycodes, so that folks can use xmodmap to make their own changes, would also be short but massively helpful. That's truly not a lot of writing, especially when most of that would be merely a sentence of two, and it's VERY badly needed. I wish I personally knew enough to do this, but I can't, I just don't know the answers. But doing this would be a big service to all newbies. Most of the Pandora's docs do things like telling users to "click the mouse button" when there are no mice on the Pandora, and the Pandora work-alike for mouse isn't at all obvious. All of the other keys & controls are similarly an unintentional secret. Using terms like mouse are making the docs sound more friendly, but in fact, it's unfortunately not helpful at all. I'll bet that the OP team fellas are so used to how things are laid out that they're unaware of how confusing using ordinary terms like mouse (that either don't exist on the Pandora or are not in the ordinary places) actually make things more confusing. I'm sorry to be making criticisms like this, when in actuality, I am so impressed with the Pandora that I haven't sufficient words to express it.

 

[Chero]

check out this page : http://wiki.openmoko.org/wiki/Ipkg

The config file for opkg is /etc/opkg.conf (or /etc/opkg/opkg.conf).

after the line "dest root /" add one or more new lines:
dest SD /media/mmcblk0p1/opkg
dest SD2 /media/mmcblk1p1/opkg

Then you can use the -d option to install apps to SD or SD2.
You can also set the default dest in the same file (it's obvious, just check the file).

As said, I used this setup during the first weeks I had my pandora. Since I found the rootfs tarball and I'm able to boot from SD, there is no more need to use this special features that opkg and ipkg have.
I'm keeping my NAND install as clean as possible (actually I haven't used it during the last two weeks ...), I'm using an SD card for testing purposes and another SD for a full featured install (a lot of apps installed, debian extend, game-pnds and emulator-pnds, swap).

Have fun,
Chero.