linaro-infrastructure-stakeholders team mailing list archive

[Alexander Sack <asac@xxxxxxxxxx>]

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).

-- 

 - Alexander