(Created page with "= MeeGo Buildsystem Roadmap = == Current Status == MeeGo is currently running OBS 2.0.6 with minor changes specific to MeeGo: * Backport of notification plugin to be able to use …") |
(→LDAP integration) |
||
| Line 20: | Line 20: | ||
* Migrate users to LDAP and run initial tests with LDAP as the backend. At that time, user creation and user changes is frozen and disabled. | * Migrate users to LDAP and run initial tests with LDAP as the backend. At that time, user creation and user changes is frozen and disabled. | ||
* finally, migrate to LDAP and disable current database backend | * finally, migrate to LDAP and disable current database backend | ||
| + | |||
| + | === Build System Project Reorg === | ||
| + | |||
| + | At the moment, projects are organised based on usage scenarios or verticals. the main project is Trunk with the following vertical/UX based projects: | ||
| + | * Trunk:Netbook | ||
| + | * Trunk:Handset | ||
| + | * Trunk:IVI | ||
| + | |||
| + | The vertical projects build against Trunk, thus, the Trunk is the container for all share packages required by all verticals. With the introduction of the compliance and the need to have a self-contained core stack, based on the MeeGo architecture, the above model does not scale and causes conflicts among verticals and does not provide a clear view of what exactly the base stack that can be used to build compliant applications. | ||
| + | |||
| + | |||
| + | Hence, we have the following proposal to split the whole lot into 2 groups instead . | ||
| + | |||
| + | - Core | ||
| + | - Reference or Applications (tentative name) | ||
| + | |||
| + | '''Core''' would have all compliance libraries and OS base packages (essentials) and their | ||
| + | build requirements. All misc. stuff like reference apps, tools and | ||
| + | non-core libraries would go into the '''Applications''' project and build on top of Core. | ||
| + | |||
| + | There are two major advantages here: | ||
| + | * We can always guarantee that the core packages are self contained and | ||
| + | consistent without any bogus dependencies | ||
| + | * When building compliant applications all you need is to build against | ||
| + | '''Core''' which will guarantee that you do not link against libraries that are | ||
| + | not available on all devices | ||
| + | |||
| + | We started experimenting and have been splitting Trunk packages into | ||
| + | core+application in the following devel area in the MeeGo Build System: | ||
| + | |||
| + | * devel:cleanup:core | ||
| + | * devel:cleanup:reference | ||
| + | |||
| + | This effort still ongoing and doing this we are already identifying lots of issues and dependencies that should not be there and cleaning those up as | ||
| + | we go. | ||
Contents |
MeeGo is currently running OBS 2.0.6 with minor changes specific to MeeGo:
We are on track to update the MeeGo Build System to 2.1.1 which was released Oct 29th, 2010. See the original announcement for 2.1 for more details about the new features and fixes.
The update to 2.1.1 is scheduled to happen on Saturday, November 6th. Downtime is scheduled between 12:00-14:00 GMT on that date.
2.1.x adds enhanced LDAP support which will allow advanced user management. We are planning to migrate all users from the current implementation to a dedicated LDAP instance and finally enable password changes by the user and better tracking for users and groups in general. The migration to LDAP will happen after 2.1.1 deployment and will happen in 2 steps:
At the moment, projects are organised based on usage scenarios or verticals. the main project is Trunk with the following vertical/UX based projects:
The vertical projects build against Trunk, thus, the Trunk is the container for all share packages required by all verticals. With the introduction of the compliance and the need to have a self-contained core stack, based on the MeeGo architecture, the above model does not scale and causes conflicts among verticals and does not provide a clear view of what exactly the base stack that can be used to build compliant applications.
Hence, we have the following proposal to split the whole lot into 2 groups instead .
- Core - Reference or Applications (tentative name)
Core would have all compliance libraries and OS base packages (essentials) and their build requirements. All misc. stuff like reference apps, tools and non-core libraries would go into the Applications project and build on top of Core.
There are two major advantages here:
consistent without any bogus dependencies
Core which will guarantee that you do not link against libraries that are not available on all devices
We started experimenting and have been splitting Trunk packages into core+application in the following devel area in the MeeGo Build System:
This effort still ongoing and doing this we are already identifying lots of issues and dependencies that should not be there and cleaning those up as we go.