Lothar Behrens wrote: > 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.
risk of the user ;) I would only install packages with stuff like fonts, keyboards etc. and only if they are not available in the default repositories. let's keep it simple. > > 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 <pan...@users.sourceforge.net>: >>>>>> 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 <lothar.behr...@lollisoft.de>: >>>>>>>> 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 >>>>>>>> community@lists.openmoko.org >>>>>>>> http://lists.openmoko.org/mailman/listinfo/community >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Openmoko community mailing list >>>>>>> community@lists.openmoko.org >>>>>>> http://lists.openmoko.org/mailman/listinfo/community >>>>>> _______________________________________________ >>>>>> Openmoko community mailing list >>>>>> community@lists.openmoko.org >>>>>> http://lists.openmoko.org/mailman/listinfo/community >>>>>> >>>>> _______________________________________________ >>>>> Openmoko community mailing list >>>>> community@lists.openmoko.org >>>>> http://lists.openmoko.org/mailman/listinfo/community >>>> _______________________________________________ >>>> Openmoko community mailing list >>>> community@lists.openmoko.org >>>> 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 >>> community@lists.openmoko.org >>> http://lists.openmoko.org/mailman/listinfo/community >> >> _______________________________________________ >> Openmoko community mailing list >> community@lists.openmoko.org >> 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 > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community