Yes, I agree with that when data should be used from sdcard, if there are these files. That would be the quick hack in my mind.
But I brought up my points in case if there are applications for specific distros and versions that may be incompatible to each other? I don't know if the issue will make the whole thing too complex, but I thought to discuss about it. I have had a case where I gone back to an older version, but it didn't worked any more and I didn't know, wich versions do fit together. Am 09.04.2009 um 01:02 schrieb Pander: > A directory called > /media/card/post/linked > with e.g. files like > /media/card/post/linked/root/.cellhunter > /media/card/post/linked/root/Maps/ > the original /root/.cellhunter file and /root/Maps directory will be > deleted and a soft link will be created to the ones in linked > directory. > > Lothar Behrens wrote: >> Ok, as the idea was good, more thoughts: >> >> 1.) Using the sd card to store jet installed application information >> is not good. Then it would only run the first distro switch. >> 2.) Keep in mind, that packages from the usual opkg may be installed >> in later releases. And it may or may not reinstalled. >> 3.) Using a database repository in the net to update a local database >> of applications that may installable without problems >> per distro. >> 4.) If a user add's an application with opkg, a choice could be made >> to activate autoinstall for later switches. >> 5.) If the application isn't in the database on the net, or the local >> copy, add it but mark it as untested. >> 6.) The database could be used for a hitlist of installed >> applications >> that would really used, because a reinstall could be counted. >> 7.) Untested applications that should be installed, could be >> complained about and a choice could be made. >> 8.) Feedback if successfully installed application makes problems. >> The >> user should be asked some time later and he/she may make choices >> as of like this: 'App1 is usable', 'App2 has problems on this >> distro' >> and so forth. >> >> That way, we get feedback of the most used applications, we see the >> quality in the installability and we may spot conflicts. >> >> Next, if a distro decides to add an application as default, it could >> be marked as installed by that distro. This leads propably to an >> update process >> per distro and thus a local copy (if there will be really some for >> offline installations) could either removed any time - by asking or >> the app on the >> card could also get updated. >> >> Keep in mind that there are issues with the applications data. If >> this >> data is not at least backed up to sd card, a distro switch may kill >> your data :-) >> >> Also keep in mind, that users don't want to give that feedback. We >> don't do it like some companies do collect their statistical :-) >> >> It is not easy and I don't like to only create a quick hack, that >> would not work at all. >> >> Lothar >> >> Am 08.04.2009 um 16:28 schrieb Pander: >> >>> in the first boot, also make the most default choices of all when >>> /media/card/post directory is found. e.g. English, Illume SHR theme, >>> ..., next, next, next, finish ;) >>> >>> Johny Tenfinger wrote: >>>> Hmm... Maybe there is a place for some app... "shr-firstboot" :) It >>>> could also replace first boot creator from e17, which isn't very >>>> useful on Neos... >>>> >>>> 2009/4/8, Pander <[email protected]>: >>>>> good idea. I already have all those files on SD but after each >>>>> upgrade >>>>> have to install them manually, which is annoying. >>>>> >>>>> I would suggest something like: >>>>> >>>>> 1) notify user to do an opkg update and opkg upgrade first >>>>> >>>>> 2) change to post installation directory >>>>> cd /media/card/post >>>>> >>>>> 3) change to package directory and install all that is in there >>>>> cd packages >>>>> opkg install *.ipk *.opk >>>>> cd .. >>>>> >>>>> 4) override files >>>>> cd override >>>>> [[copy all files to root of system, e.g. override/etc/blabla to >>>>> /etc/blabla]] >>>>> cd .. >>>>> >>>>> 5) path files >>>>> cd patches >>>>> [[apply all patchers to root of system]] >>>>> cd .. >>>>> >>>>> off course documenting your changes via patches/diffs is preferred >>>>> over >>>>> overriding, allowing improvements in other parts of the files via >>>>> opkg >>>>> upgrade before you start. >>>>> >>>>> Johny Tenfinger wrote: >>>>>> Shortly: Let's write it ;) >>>>>> >>>>>> 2009/4/8, Lothar Behrens <[email protected]>: >>>>>>> There is an idea rattling in my head about the following issue: >>>>>>> >>>>>>> Given I have a micro SD card and that would have all here, >>>>>>> what is >>>>>>> about a bootstrap mechanism to >>>>>>> post install packages that are laying on that card to be >>>>>>> installed, >>>>>>> when a new image is started at first time? >>>>>>> >>>>>>> Like the autorun of a CD, this would help to ease the distro >>>>>>> switch >>>>>>> but keep my usual applications that otherwise >>>>>>> have to be installed manually. >>>>>>> >>>>>>> This would include SSH settings, WLAN settings, look and feel, >>>>>>> and >>>>>>> what ever may possible. >>>>>>> >>>>>>> What about it? >>>>>>> >>>>>>> -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de >>>>>>> Lothar Behrens >>>>>>> Heinrich-Scheufelen-Platz 2 >>>>>>> 73252 Lenningen >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Openmoko community mailing list >>>>>>> [email protected] >>>>>>> http://lists.openmoko.org/mailman/listinfo/community >>>>>>> >>>>>> _______________________________________________ >>>>>> Openmoko community mailing list >>>>>> [email protected] >>>>>> http://lists.openmoko.org/mailman/listinfo/community >>>>> _______________________________________________ >>>>> Openmoko community mailing list >>>>> [email protected] >>>>> http://lists.openmoko.org/mailman/listinfo/community >>>>> >>>> _______________________________________________ >>>> Openmoko community mailing list >>>> [email protected] >>>> http://lists.openmoko.org/mailman/listinfo/community >>> >>> _______________________________________________ >>> Openmoko community mailing list >>> [email protected] >>> http://lists.openmoko.org/mailman/listinfo/community >>> >> >> -- | Rapid Prototyping | XSLT Codegeneration | http:// >> www.lollisoft.de >> Lothar Behrens >> Heinrich-Scheufelen-Platz 2 >> 73252 Lenningen >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Openmoko community mailing list >> [email protected] >> http://lists.openmoko.org/mailman/listinfo/community > > > _______________________________________________ > Openmoko community mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/community > -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
