iLiad Question to Adam. B

[smoogle]

Hey, Adam B,

I'm yet to recieve my shell account, so can't try this for myself; but does the iLiad have the appropriate libraries to call getexecname()

Could you just attempt to run this simple program on the iLiad?

---

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char** argv) {
char const* ename = getexecname();
if(ename) {
printf("%s",ename);
}
}

---

Given your sources to fbreader that you have modified, I can make an adjusted version that will not require a fixed installation directory- I believe this would simplify things?

Basically the idea is, in all these programs that make use of certain defines, in the case of fbreader BASEDIR/HOMEDIR, for fbreader it does so in zlibrary/abstract/application;
ZLApplicationBase::BaseDirectory

By adjusting this to dynamically look for the location of the executable, we can then produce self-contained versions of the program, an example structure:

Programs
- fbreader
--- fbreader [ executable ]
--- _data
-----... usual contents of share/etc go in here ...


I would say applying this to other applications, for instance AbiWord, would be of immense benefit - as then installing any application would not at all touch the root filesystem.

The disadvantage to this method is cases where applications share data; as in suppose AbiWord uses fbreader's icons (I have just made up this dependancy for example's sake); in which case due to our self-contained structure they would not reference each other and we'd need two copies of the data.

This could of course be fixed by having AbiWord dynamically resolve where fbreader is installed- which could be done by adjusting the above structure, but I think baby steps first.

[Antartica]

Originally Posted by Adam B.

I can include dillo, mrxvt, keyboard driver, etc if the dev's don't mind.

Of course you can do whatever you want to the dillo port ;-).

Having more easily installable programs for the average user is always a plus.

BUT having dependencies means that the user will have to track them, and I'm not so sure if this is desirable.

The only way I think this could work (without having a package manager to track dependencies), is to have every program have all the needed dependencies and making the install script deletes the duplicated ones.

One way to do it would be:

1) Install the program in a subdirectory for himself
2) check if some of it files are in the common directory, and if so, delete them and for each file deleted (say foobar.so), add to a file in the common directory (say foobar.so.depinfo) the name of the app that's is using it (for example Dillo).
3) check if some of the files are in the private directories of the other programs, and if they are, copy them (for example foobar.so) to the shared directory and add to the depinfo (for example foobar.so.depinfo) both apps names. And delete the original versions from the original directories.

It would be interesting to leave in the original places a 0-size file with the name foobar.so.moved, so a script can be done to track those files and regenerate the installation file from the live filesystem (I say this because when I pack a new version of dillo, I just pack the one I've tested in my iliad, and it's very useful to be able to do so).

What do you think about it?

EDIT: I can make the scripts if you want to give it a try.

[Adam B.]

Originally Posted by Antartica

The only way I think this could work (without having a package manager to track dependencies), is to have every program have all the needed dependencies and making the install script deletes the duplicated ones.

The script you described sounds like the best way to do it. With more and more programs being ported, all these duplicate libraries are getting a bit ridiculous. If you want to write that, that would be great.

[Adam B.]

Originally Posted by smoogle

Could you just attempt to run this simple program on the iLiad?

I'll give that a try a bit later this morning.


The problem is that I've never been able to define a dynamic location when compiling the programs. Any help to do this would be great. Like I've mentioned before, I haven't been doing this for too long, so my way is probably not the best.

[mtas]

Originally Posted by Adam B.

The script you described sounds like the best way to do it. With more and more programs being ported, all these duplicate libraries are getting a bit ridiculous. If you want to write that, that would be great.

As I see it it might be time to start looking at using ipkg. In that way the problems regarding duplicated libs and dependencies could be reduced.

[narve]

Originally Posted by mtas

As I see it it might be time to start looking at using ipkg. In that way the problems regarding duplicated libs and dependencies could be reduced.

ipkg would be great, if it is reasonably simple to create ipkg packages. Perhaps even a content lister action for ipkg-files... ?

[mtas]

Originally Posted by narve

ipkg would be great, if it is reasonably simple to create ipkg packages. Perhaps even a content lister action for ipkg-files... ?

I'll look into it, it shouldn't be any harder than creating any other type of installation package such as dpkg, rpm or Solaris pkg files.

What can be a potential problem though is the libraries that are used by more than one program. To get that to work properly those would have to be broken out into their own packages.

[Adam B.]

Originally Posted by smoogle

Given your sources to fbreader that you have modified, I can make an adjusted version that will not require a fixed installation directory- I believe this would simplify things?

The version in the developer upload area is quite old. Unfortunately, I reset my development area without saving my modified sources. I've made changes to the most recent version, and am attaching them. They haven't been tested (I forgot my iLiad at home today ), but they compile, and I think I remembered everything.

[smoogle]

Just got the iDS shell script access, networking and ssh and unbrickable all installed- waiting for the toolchain to finish downloading before I can test my location-independant fbreader

[Henry Loenwind]

I like the idea of using ipkg to install third party programs. But one suggestion: Someone should define a directory structure first, so we don't get a big mixed-up disorder...

Allow me to start:

---

(1) Prior to installing the iLiad must be prepared:

mkdir /mnt/cf/opt && ln -s /mnt/cf/opt /opt
or
mkdir /mnt/card/opt && ln -s /mnt/card/opt /opt

mkdir /opt/lib
mkdir /opt/bin
mkdir /opt/etc
mkdir /opt/var
mkdir /opt/programs

One of these, as fs allows:
ln -s /opt/programs /mnt/cf/programs
ln -s /opt/programs /mnt/card/programs

(2) Installation packages should follow these rules:

• All files shall be installed into /opt, no other part of the filesystem may be touched.
• If the program is to be started directly (content lister sh-extension), it shall be installed into /opt/programs. It shall have its MANIFEST in its top-level folder (e.g. /opt/programs/fbreader/MANIFEST.xml).
• Common shared libraries (.so) go into /opt/lib.
• Configuration settings for into /opt/etc. Using a subfolder is recommended if having more than one file, e.g. /opt/etc/fbreader/.
• Programs that are to be started from the command line, or that are added as content handler to the content lister, go into /opt/bin.

---

I think putting a single link into the root fs is a better way to handle the CF/SD duality then creating two installation packages for each program. Now I just hope /opt is not yet taken, didn't check it...

Is this a reasonable start? What do you developers think about it?

[Adam B.]

It looks like we're all on the same page. I just made a thread about standardization. Maybe we should bring the conversation there: https://www.mobileread.com/forums/showthread.php?t=10442