linaro-infrastructure-stakeholders team mailing list archive

[Alexander Sack <asac@xxxxxxxxxx>]

On Mon, May 30, 2011 at 12:33 PM, Alexander Sack <asac@xxxxxxxxxx> wrote:
> On Mon, May 30, 2011 at 12:14 PM, Mattias Backman
> <mattias.backman@xxxxxxxxxx> wrote:
>> On Mon, May 30, 2011 at 11:30 AM, Alexander Sack <asac@xxxxxxxxxx> wrote:
>>> On Mon, May 30, 2011 at 11:19 AM, Mattias Backman
>>> <mattias.backman@xxxxxxxxxx> wrote:
>>>> On Fri, May 27, 2011 at 2:55 PM, Loïc Minier <lool@xxxxxxxx> wrote:
>>>>>        Hey
>>>>>
>>>>>  The Android support in Linaro Image Tools feels like a second class
>>>>>  citizen; it was a bit rushed in, and to my knowledge didn't get the
>>>>>  chance to be architectured properly into linaro-image-tools so that it
>>>>>  would be on equal footing with the Ubuntu-based images.
>>>>>
>>>>>  It would be nice to chance this so that it's clearly owned and well
>>>>>  supported; how do we get this ball rolling?
>>>>>
>>>>>  AFAIK, the only spec on linaro-image-tools for next cycle is hwpackv2
>>>>>  which is kind of unrelated.  Who would be interested in discussing
>>>>>  evolutions to the design of the Android support in Linaro Image Tools
>>>>>  and who would be interested in participating in the implementation?
>>>>
>>>> I would be interested in both aspects and I agree that something needs
>>>> to be done so the two scripts don't diverge entirely. Whether it's a
>>>> good idea that I spend time on this is of course up to James.
>>>
>>> How bad is the maintainability for the android script for the time
>>> being? e.g. how urgent is it?
>>
>> It's not terribly urgent, in my view it's more the fact that the
>> Android script reuses some parts of l-m-c and overrides others and is
>> pretty unknown to me. But how changes are to be handled has to be
>> discussed since there already are uncertainty about what the scripts
>> should support, for instance using the android script to create images
>> or not. There are also four separate ways to handle partitions
>> (android vs ubuntu based and image/mmc for both) which to me looks
>> hard to maintain and possibly could be made easier by changing to the
>> image/dd approach and stop partitioning mmc:s directly. For that kind
>> of changes in l-i-t we need to consider both scripts so we don't end
>> up with two entirely separate tracks.
>>
>>>
>>> With the info that we might change what artifacts we provide/install
>>> in a 1-2 month timeframe, would a cleanup now still make sense in your
>>> opinion?
>>
>> I don't think it is a reason to postpone changes, at least not if the
>> partition layout will remain the same or similar. The code that
>> assumes that the artifacts are those three tarballs is really minimal.
>> The major parts is concerning partitioning. Will we build a system.img
>> instead of a system tarball etc, or will the artifacts be something
>> else entirely do you think?
>>
>
> moving to .img is one possibility yes. Probably depends how the
> fastboot story turns out (but here, I don't have a clue if .img and
> fastboot flashing is connected at all - but I might think it is).

in an extreme scenario we might produce:

 1. 3 tarballs as now
 2. 3 images ext4
 3. 3 images yaffs2
 4. overlay tarball that asks for license on install and gets
overlayed over the install.

-- 

 - Alexander