Extras-devel
m |
|||
Line 74: | Line 74: | ||
* Remove helper files from copyright, check for properly assigned copyright | * Remove helper files from copyright, check for properly assigned copyright | ||
* Make sure the Architecture field is correct according to debian specifications. I.e. all, any, or a specific arch - multiple arches not allowed. | * Make sure the Architecture field is correct according to debian specifications. I.e. all, any, or a specific arch - multiple arches not allowed. | ||
+ | |||
+ | [[Category:Development]] |
Revision as of 14:39, 29 October 2009
The software hosted in extras-devel is most likely not ready for end users! PLEASE PLEASE PLEASE don't play with it unless you really know what you are doing. Expected problems: crashes, battery drain, poor system performance, full disk space & more - SERIOUSLY! Don't play with Extras-devel if you haven't backed up your data or are prepared to re-flash your device.
Developers upload the newest version of their software to extras-devel. From there the packages go Extras-testing and finally Extras through an automatic and human Quality Assurance process. This is a repository for developers and regular contributors of specific software projects. If you want to play with extras-devel software you need to be prepared to feel some pain sooner or later.
In order to activate extras-devel in the Application manager you need to follow the same instructions used to enable the extras-testing repository, only using "extras-devel" instead. The instructions are not made more simple just on purpose. :)
Contents |
For developers
Uploading to Extras-devel
Main article: Uploading to Extras-devel
Anyone with a Garage account can upload packages to Extras-devel in order to share new updates and start the community QA process. It is important to note that the uploader needs a Garage account: the package itself does not need to be hosted in the Garage.
Policy
Main article: Task:Consolidation of Extras
The Extras policies are still in the process of being defined and refined. See Extras repository process definition and Diablo Extras repository proposal for details and discussion.
See also the Extras/3rd Party Package Policy being tested in Fremantle.
Downloads OBSOLETE FIXME
Main article: Providing changes since last version of a package
You can create an entry for your application in the maemo.org downloads section. If the unixname of your entry is the same as your debian package in Extras, the version information will be automatically updated when you upload a new package.
There is a discussion going on about how to provide changes since last version of a package. At the moment there isn't a conclusion to this discussion yet.
Promoting packages to extras-testing
Developers can tinker as much as they want in the extras-devel repository. Once they think their an application is ready to go public they need to promote it to extras-testing following these steps:
1. Go to the armel version of your application.
- This will be at maemo.org > packages > Fremantle Extras-devel free armel > packagename > version
2. Check if you are listed as maintainer for the package.
- This should correspond to your login name - you must be logged in
3. Check if there is a 'Promote package' link, if there is: click it
- This is normally in the lower-right corner of the package description
If there are no errors shown your application will be promoted to extras-testing. This can take some time.
In case there are warning or errors on the details page of your package, please try to resolve these issues first. If the interface doesn't detect any problem, it will unlock the 'Promote package' link automatically.
You don't have to promote the i386 versions of your packages, they will be promoted automatically.
A promotion can fail because your application depends on an other 'user/*' category application. In this case you need to promote the other application first and wait until that package shows up in Extras-testing.
Promotion checks
The package interface will try to prevent promotion for packages with known issues. The following tests are in place:
- Application is using one of the official 'user/*' sections.
- Promoting person is maintainer for the package.
- All specified dependencies can be found in the origin repository or neighbour repositories.
- All specified version dependencies are met.
- Application doesn't depend on another 'user/*' application which hasn't been promoted yet.
- Check if all dependencies which are in origin and not in target can be promoted.
- Check dependencies of dependencies. (Check complete tree)
- Check if the application hasn't been promoted already
Maemian/Minimae checks after builds
Jeremiah is implementing the following checks in minimae for this Sprint:
- Control information is UTF-8
- Control file contains an image (Not having an image is not an error, it's just that minimae should notice if there is an image or not, its size and type. This check is only done for user/ apps since libs have no icon.)
- XB- (or XS-) Fields in control file
- Version is consistent with what is in changelog
- Use of trademarked names in package (not in version string.) i.e. A package cannot be called MaemoCamera or MaemoMusic since that is use of a registered trademark.
- Make sure the name of the binary package that gets built is the same as the package name. i.e. a package called foo should build a binary called foo, not bar.
- Each package has to have a copyright file
- Copyright file cannot be compressed, i.e. zipped
- Remove helper files from copyright, check for properly assigned copyright
- Make sure the Architecture field is correct according to debian specifications. I.e. all, any, or a specific arch - multiple arches not allowed.