Autorun for SD card mechanism?

[Pander]

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