Autorun for SD card mechanism?

Thu Apr 9 03:02:39 CEST 2009

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 <pander at 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.behrens at 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 at lists.openmoko.org
>>>>>>> http://lists.openmoko.org/mailman/listinfo/community
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Openmoko community mailing list
>>>>>> community at lists.openmoko.org
>>>>>> http://lists.openmoko.org/mailman/listinfo/community
>>>>> _______________________________________________
>>>>> Openmoko community mailing list
>>>>> community at lists.openmoko.org
>>>>> http://lists.openmoko.org/mailman/listinfo/community
>>>>>
>>>> _______________________________________________
>>>> Openmoko community mailing list
>>>> community at lists.openmoko.org
>>>> http://lists.openmoko.org/mailman/listinfo/community
>>>
>>> _______________________________________________
>>> Openmoko community mailing list
>>> community at 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 at lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>
>
> _______________________________________________
> Openmoko community mailing list
> community at 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