[maemo-developers] Autobuilder repository priority ?

[From: Jeremiah Foster]

On Nov 1, 2009, at 18:05, Ed Bartosh wrote:

> 2009/11/1 Attila Csipa <maemo at csipa.in.rs>:
>> On Sunday 01 November 2009 07:46:55 you wrote:
>>> So, you propose to have one more queue, which would use only SDK? Or
>>> only Extras? or both? Sorry, your proposal is still unclear to me  
>>> and
>>> I doubt it would be clear for other devs.
>>
>> First we need to decide on whether Extras packages can update  
>> packages from
>> the SDK/official repos.

I don't think any Extras packages should update official SDK repos.

> It depends on type of packages. SDK contains 2 parts: developer tools
> & libs, which are not installed on the device and libs & apps, which
> are installed on the device.

Can't we have a monolithic repo which is _identical_ to the device,  
plus dev tools? This would allow developers to know in advance which  
dependencies are on the device and which dependencies they will have  
to pull in themselves.

> For first group updating through Extras is not good, but possible and
> most of the time it would work faster than through SDK update
> process(if it exists at all).
> Packages from second group can break SSU if they they're considered as
> a system packages. Actually, application manager doesn't allow to
> install them, but if installed using dpkg they can break SSU.
>
> Another concern here is that SDK and device firmware usually released
> together, but packages in Extras are not synchronized with those
> releases until they appear. It practically means that it's better to
> avoid overlapping SDK/Extras as much as possible. However it's still
> unclear to me what to do with components taken into SDK from projects
> similar to PyMaemo with their own release circle and distributing
> scheme.

I'd say that a lot of the Maemo release is still driven by corporate  
Nokia goals which Maemo.org people and the community have to implement  
the community tools to co-incide with that. This is really hard to do.  
I think that those in charge of this system have done a great job, but  
it would be much easier for them and for developers if more of the SDK  
and device software could be maintained by the community. This is how  
it is done in debian, and debian is a production quality operating  
system. Doing it half-open, half-closed is not scaling well -  
developers need greater insight into the dependency chain, the build  
tools, and the device software - otherwise Nokia is asking them to  
develop with one eye.

>
>> I'd say no. In that case, go the Debian way and have an
>> sdk-updates and extras-updates queue with a different QA procedure.
> Maemo isn't Debian. Debian has consistent repository one for
> everything. Maemo has at least 3 different components(SDK, Extras,
> device packages) and 2 different operation environments(scratchbox and
> device). SDK has never been released through Extras, so separate queue
> for SDK updates should be agreed with SDK team. I doubt they need it.

This is what makes things so hard for developers.
>
> Idea of having separate queue for Extras updates sounds more promising
> to me. Developers might become confused with all this set of
> repositories, queues and processes, but the idea is good. I support
> this.
>
>>
>> In case of overlapping SDK/Extras I can't think of a satisfactory  
>> solution as
>> then fixes for the latter would appear as fixes for the former,  
>> which is wrong
>> and dangerous. Another issue would be that you would not be getting  
>> SDK
>> updates if you have extras or extras-updates disabled, which is very
>> counterintuitive.
>>
> True. I also don't see any more or less acceptable solution for this.

Having a single repo for each distro would be ideal, with _all_ the  
software required to run the device in the repo. Then we can co- 
ordinate the release as a single, monolithic repository. I know this  
is wishful thinking because not everything is licensed to allow this,  
but if we could get as much as possible in a single location, then we  
make life easier for developers.

Jeremiah