Autorun for SD card mechanism?

[Lothar Behrens]

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