特殊:Badtitle/NS101:UbuntuDevelopment/PackageArchive:修订间差异

来自Ubuntu中文
跳到导航跳到搜索
Wikibot留言 | 贡献
无编辑摘要
Wikibot留言 | 贡献
无编辑摘要
 
(未显示同一用户的3个中间版本)
第1行: 第1行:
{{From|https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive}}
{{From|https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive}}
{{Languages|UbuntuWiki:UbuntuDevelopment/PackageArchive}}
{{Languages|UbuntuWiki:UbuntuDevelopment/PackageArchive}}
[[Include(UbuntuDevelopment/Header/Menu)]]
<<Include(UbuntuDevelopment/Header/Menu)>>
=== The Package Archive ===
== The Package Archive ==
All current official Ubuntu packages are stored in the master archive, which is widely [[UbuntuWiki:Mirrors|mirrored]].  A search interface is available at [http://packages.ubuntu.com].  Old versions can be retrieved from [http://launchpad.net/ubuntu Launchpad].
All current official Ubuntu packages are stored in the master archive, which is widely [[UbuntuWiki:Mirrors|mirrored]].  A search interface is available at [http://packages.ubuntu.com]].  Old versions can be retrieved from [[http://launchpad.net/ubuntu Launchpad].
It is administered by the [http://launchpad.net/~ubuntu-archive archive administration team].
It is administered by the [http://launchpad.net/~ubuntu-archive archive administration team].
[[Anchor(Uploading)]]
<<Anchor(Uploading)>>
==== Uploading ====
=== Uploading ===
If you are not yet an official Ubuntu developer, you can arrange for your package to be uploaded via the [[UbuntuWiki:SponsorshipProcess|SponsorshipProcess]].
If you are not yet an official Ubuntu developer, you can arrange for your package to be uploaded via the [[UbuntuWiki:SponsorshipProcess|SponsorshipProcess]].
Packages are uploaded via FTP to ftp://upload.ubuntu.com/ using `dput` or `dupload`.
Packages are uploaded via FTP to ftp://upload.ubuntu.com/ using `dput` or `dupload`.
Notes for preparing your upload:
Notes for preparing your upload:
* Make source-only uploads, i.e. use "``dpkg-buildpackage -S``"
* Make source-only uploads, i.e. use "``dpkg-buildpackage -S``"
* When uploading to [[UbuntuWiki:MOTU/Packages/REVU]], please include the orig tarball as well (use parameters `-S -sa`)
* When uploading to [[UbuntuWiki:MOTU/Packages/REVU|MOTU/Packages/REVU]], please include the orig tarball as well (use parameters `-S -sa`)
When your upload is processed (typically within a matter of minutes), you will receive an email with the result of your upload, whether it succeeds or fails, '''unless''' you use an unregistered email address.  The system will only send mail to an address which belongs to a launchpad account which is a member of the relevant team for uploading. E.g. [http://launchpad.net/people/ubuntu-dev ubuntu-dev] for universe and [http://launchpad.net/people/ubuntu-core-dev ubuntu-core-dev] for main.
When your upload is processed (typically within a matter of minutes), you will receive an email with the result of your upload, whether it succeeds or fails, '''unless''' you use an unregistered email address.  The system will only send mail to an address which belongs to a launchpad account which is a member of the relevant team for uploading. E.g. [http://launchpad.net/~motu motu] for universe and [http://launchpad.net/~ubuntu-core-dev ubuntu-core-dev] for main.
Your upload must be signed by GPG key registered in launchpad. If the signature cannot be traced to a member of the appropriate team, then the upload will be '''silently rejected'''.
Your upload must be signed by a GPG key registered in Launchpad. If the signature cannot be traced to a member of the appropriate team, then the upload will be '''silently rejected'''.
To add a new package to Ubuntu, simply upload it as usual.  Any new packages uploaded are put in a [https://launchpad.net/ubuntu/gutsy/+queue queue] to be checked by the administrators before being included.
To add a new package to Ubuntu, simply upload it as usual.  Any new packages uploaded are put in a [https://launchpad.net/ubuntu/karmic/+queue queue] to be checked by the administrators before being included.
[[Anchor(Publishing)]]
[[UbuntuWiki:UbuntuDevelopment/Uploading|UbuntuDevelopment/Uploading]] has much more information about the topic.
==== Autobuilding and Publishing ====
<<Anchor(Publishing)>>
Once an upload has been accepted, it takes some time to be [[Autobuilders built]] and published in the archive.  For simple packages, this is usually on the order of an hour, but varies depending on release activity (uploads may be temporarily suspended), the time needed to build the package (including other packages in the build queue), and other factors.
=== Autobuilding and Publishing ===
[[Anchor(Notification)]]
Once an upload has been accepted, it takes some time to be [[UbuntuWiki:[Autobuilders|built]]] and published in the archive.  For simple packages, this is usually on the order of an hour, but varies depending on release activity (uploads may be temporarily suspended), the time needed to build the package (including other packages in the build queue), and other factors.
==== Notification of changes ====
After a package has been built, the next publisher run that starts at three minutes past each hour will process it, usually finishing towards the end of that hour; at the end of that process it will be visible in the public archive.
<<Anchor(Notification)>>
=== Notification of changes ===
Notifications of uploads are sent to a mailing list.  A different list is used for each Ubuntu release:
Notifications of uploads are sent to a mailing list.  A different list is used for each Ubuntu release:
* [http://lists.ubuntu.com/mailman/listinfo/dapper-changes/ dapper]
* [http://lists.ubuntu.com/mailman/listinfo/dapper-changes/ dapper] ([http://feeds.ubuntu-nl.org/DapperChanges RSS])
* [http://lists.ubuntu.com/mailman/listinfo/edgy-changes/ edgy]
* [http://lists.ubuntu.com/mailman/listinfo/hardy-changes/ hardy] ([http://feeds.ubuntu-nl.org/HardyChanges RSS])
* [http://lists.ubuntu.com/mailman/listinfo/feisty-changes/ feisty]
* [http://lists.ubuntu.com/mailman/listinfo/intrepid-changes intrepid] ([http://feeds.ubuntu-nl.org/IntrepidChanges RSS])
* [http://lists.ubuntu.com/mailman/listinfo/gutsy-changes/ gutsy]
* [http://lists.ubuntu.com/mailman/listinfo/jaunty-changes jaunty] ([http://feeds.ubuntu-nl.org/JauntyChanges RSS])
* [http://lists.ubuntu.com/mailman/listinfo/hardy-changes/ hardy]
* [http://lists.ubuntu.com/mailman/listinfo/karmic-changes karmic] ([http://feeds.ubuntu-nl.org/KarmicChanges RSS])
RSS Feeds of these messages are available at [http://media.ubuntu-nl.org/rss/].
Changelogs for all packages are available at http://changelogs.ubuntu.com/changelogs/ (this is the source used by update-manager and Synaptic).
Changelogs for all packages are available at http://changelogs.ubuntu.com/changelogs/ (this is the source used by update-manager and Synaptic).
[[Anchor(SyncingAndMerging)]]
<<Anchor(SyncingAndMerging)>>
==== Syncing and Merging ====
=== Syncing and Merging ===
(See the [[UbuntuWiki:../ReleaseProcess#MergeProcess rationale]].)
(See the [[UbuntuWiki:UbuntuDevelopment/ReleaseProcess#MergeProcess rationale|ReleaseProcess#MergeProcess rationale]].)
Most packages in Ubuntu originate elsewhere, including Debian and related package repositories.
Most packages in Ubuntu originate elsewhere, including Debian and related package repositories.
A '''sync''' copies a source package verbatim from an external repository into Ubuntu, overwriting any package of the same name.  This is used when a newer version of it is available, and should be included in Ubuntu, and happens automatically during some phases of the release cycle.  To request a sync, follow the [[UbuntuWiki:SyncRequestProcess|SyncRequestProcess]].
A '''sync''' copies a source package verbatim from an external repository into Ubuntu, overwriting any package of the same name.  This is used when a newer version of it is available, and should be included in Ubuntu, and happens automatically during some phases of the release cycle.  To request a sync, follow the [[UbuntuWiki:SyncRequestProcess|SyncRequestProcess]].
A '''merge''' is a three-way merge of a package which originated in an external repository.  This is used when there is a newer version available from the external repository, but the package has also been modified (branched) in Ubuntu.  [http://merges.ubuntu.com/ Merge-o-Matic] assists with this work, and [[UbuntuWiki:../Merging|the Merging page]] explains how and when to merge.  Packages which are [[UbuntuWiki:UbuntuDevelopment/#Bazaar|maintained in Bazaar]] can and should be merged using Bazaar itself.
A '''merge''' is a three-way merge of a package which originated in an external repository.  This is used when there is a newer version available from the external repository, but the package has also been modified (branched) in Ubuntu.  [[http:/Merging|the Merging page]] explains how and when to merge.  Packages which are [[UbuntuWiki:UbuntuDevelopment/#Bazaar|maintained in Bazaar]] can and should be merged using Bazaar itself.
The "Last Uploader" column in the Merge-o-Matic output is the default assignee for the merge, following the touched-it-last maintenance principle. However, you can and often should grab other people's merges if they don't have time or you feel you can do a better job. It's polite and often a good idea (though not mandatory) to contact the other person first to make sure you aren't duplicating work.
The "Last Uploader" column in the Merge-o-Matic output is the default assignee for the merge, following the touched-it-last maintenance principle. However, you can and often should grab other people's merges if they don't have time or you feel you can do a better job. It's polite and often a good idea (though not mandatory) to contact the other person first to make sure you aren't duplicating work.
Backports work similarly to syncs, but have somewhat different requirements. To request a backport, follow the [[UbuntuWiki:UbuntuBackports|UbuntuBackports]] process.
Backports work similarly to syncs, but have somewhat different requirements. To request a backport, follow the [[UbuntuWiki:UbuntuBackports|UbuntuBackports]] process.
[[Anchor(Consistency)]]
<<Anchor(Consistency)>>
==== Consistency ====
=== Consistency ===
The archive is periodically checked for various inconsistencies, such as incorrect dependency relationships between packages.
The archive is periodically checked for various inconsistencies, such as incorrect dependency relationships between packages.
* http://people.ubuntu.com/~ubuntu-archive/testing/ - packages which are uninstallable due to unsatisfiable dependencies
* http://people.ubuntu.com/~ubuntu-archive/testing/ - packages which are uninstallable due to unsatisfiable dependencies
* http://conflictchecker.ubuntu.com/possible-conflicts/ - paths included in multiple packages without declaring `Replaces` or `Conflicts` or doing a diversion. Contact [[UbuntuWiki:RobertCollins|RobertCollins]] or [[UbuntuWiki:MichaelVogt|MichaelVogt]] with suggestions for improvements or questions. (Email or at #ubuntu-devel or #ubuntu-motu).
* http://conflictchecker.ubuntu.com/possible-conflicts/ - paths included in multiple packages without declaring `Replaces` or `Conflicts` or doing a diversion. Contact [[UbuntuWiki:RobertCollins|RobertCollins]] or [[UbuntuWiki:MichaelVogt|MichaelVogt]] with suggestions for improvements or questions. (Email or at #ubuntu-devel or #ubuntu-motu).
* [[UbuntuWiki:UbuntuDevelopment/NBS]] - binary packages that are no longer built by any source package. These packages are not automatically removed from the archive, since generally they still have reverse dependencies (packages depending on them).
* [[UbuntuWiki:UbuntuDevelopment/NBS|UbuntuDevelopment/NBS]] - binary packages that are no longer built by any source package. These packages are not automatically removed from the archive, since generally they still have reverse dependencies (packages depending on them).
A special case is the installer:  
A special case is the installer:  
* The `Kernel-Version:` field in the `installer` file in all the [https://code.launchpad.net/ubuntu-seeds seeds] needs to be current.
* The `Kernel-Version:` field in the `installer` file in all the [https://code.launchpad.net/ubuntu-seeds seeds] needs to be current.
* It needs to be built against the current kernel. This can be checked on the [http://archive.ubuntu.com/ubuntu/dists/gutsy/main/installer-i386/current/images/udeb.list gutsy installer's udeb list] (please also verify the other architectures).
* It needs to be built against the current kernel. This can be checked on the [http://archive.ubuntu.com/ubuntu/dists/karmic/main/installer-i386/current/images/udeb.list karmic installer's udeb list] (please also verify the other architectures).
[[Anchor(Components)]]
<<Anchor(Freezes)>>
==== Managing Components ====
=== Freezes ===
Freezes are restrictions on which changes can be uploaded in order to try and stabilize Ubuntu for release. There are various different freezes that happen at different times in the cycle, and they are of different types, affect different packages, and have different procedures for uploading during them, so understanding them all can be difficult.
You can see which freezes happen and when on the [[UbuntuWiki:ReleaseSchedule|ReleaseSchedule]], and each is linked to a page about that particular freeze, so that is a great place to go for the information. This page will provide a bit more explanation about the types of freezes and how to handle them.
Freezes are generally also announced on [http://lists.ubuntu.com/ubuntu-devel-announce ubuntu-devel-announce], so subscribing to that can keep you up-to-date. However, there aren't reminders about upcoming freezes posted to that list, so keep on top of which freezes are upcoming will help you to meet the deadlines in your work.
==== Uploading Restrictions ====
There are two ways that freezes are enforced, which are known as "soft" and "hard" freezes. Knowing whether a particular freeze is soft or hard is important, as it will allow you to know what effect uploading will have, and who needs to be aware of changes that you make for them to be included.
===== Soft Freezes =====
Soft freezes have no mechanism in the archive software to enforce them, they just rely on each developer to ensure that they only upload appropriate changes.
For instance, [[UbuntuWiki:FeatureFreeze|FeatureFreeze]] is a soft freeze, as you can still upload as before, you are just required to seek exceptions for new features.
Most importantly, freezes for the alpha releases of Ubuntu are soft freezes. This means that nothing will prevent your changes from entering the archive, so you must ensure that they don't interfere with the process of releasing the alpha. See the section on milestone freezes later for more information on what this means.
===== Hard Freezes =====
In contrast to soft freezes hard freezes flick a switch in the archive software such that all uploads are not immediately accepted, they instead end up in the UNAPPROVED Queue. Packages remain in this queue until they are explicitly accepted by an Archive Administrator.
This means that your changes can be reviewed before they are accepted, so that extra review can be done, and it is not left to your discretion to enforce the rules of the freeze.
While this could mean that you could upload with less care, it is not wise to, as those who can review are generally very busy at this time already, and extra work at these crucial periods is not appreciated. It is generally a good idea to ensure that someone on the release team knows that you will be making an upload to fix the particular issue before you do so (fixing a release critical bug is generally permission enough).
<<Anchor(Components)>>
=== Managing Components ===
Ubuntu packages are classified into components according to [http://www.ubuntu.com/ubuntu/components maintenance and licensing criteria], a process which is described in [[UbuntuWiki:SeedManagement|SeedManagement]].
Ubuntu packages are classified into components according to [http://www.ubuntu.com/ubuntu/components maintenance and licensing criteria], a process which is described in [[UbuntuWiki:SeedManagement|SeedManagement]].
Packages sometimes move from one component to another, according to policy or licensing changes, as managed by the archive administrators.  Special consideration is necessary when packages move into `main` or `restricted`, as this implies a commitment of ongoing maintenance.  Such changes must follow the [[UbuntuWiki:MainInclusionProcess|MainInclusionProcess]].
Packages sometimes move from one component to another, according to policy or licensing changes, as managed by the archive administrators.  Special consideration is necessary when packages move into `main` or `restricted`, as this implies a commitment of ongoing maintenance.  Such changes must follow the [[UbuntuWiki:MainInclusionProcess|MainInclusionProcess]].
[[Anchor(Autobuilders)]]
<<Anchor(Autobuilders)>>
==== Autobuilders ====
=== Autobuilders ===
Ubuntu source packages are automatically built for a variety of platforms by Launchpad, which provides [https://launchpad.net/ubuntu/+builds build status information].  Build log files are available from Launchpad as well, by [https://launchpad.net/ubuntu/ searching for the package] and selecting a version.
Ubuntu source packages are automatically built for a variety of platforms by Launchpad, which provides [https://launchpad.net/ubuntu/+builds build status information].  Build log files are available from Launchpad as well, by [https://launchpad.net/ubuntu/ searching for the package] and selecting a version.
Some supplementary information about the build infrastructure is available on [[UbuntuWiki:BuildDaemons|BuildDaemons]].
Some supplementary information about the build infrastructure is available on [[UbuntuWiki:BuildDaemons|BuildDaemons]].
[[Anchor(Removals)]]
<<Anchor(Removals)>>
==== Removing Packages ====
=== Removing Packages ===
Packages which are removed from Debian are semi-automatically removed from Ubuntu universe on a regular basis by the administrators.  However, packages are not removed from Ubuntu main without explicit request, nor are packages which originated elsewhere.  To request removal of such a package, file a bug against the package and '''subscribe''' the `ubuntu-archive` team.   
Packages which are removed from Debian are semi-automatically removed from Ubuntu universe on a regular basis by the administrators.  However, packages are not removed from Ubuntu main without explicit request, nor are packages which originated elsewhere.  To request removal of such a package, file a bug against the package.   
The bug must have the following elements:
The bug must have the following elements:
* which release to remove it from (ie, `hardy`)
* which release to remove it from (e.g., `hardy`)
* mention to remove both source and all binaries
* whether to remove both the source package and all binary packages
* a rationale for why to remove them
* a rationale for why they should be removed
* make sure that it has no rdepends
* confirmation that the binary packages have no rdepends (no other package depends on them)
If you are not an [[UbuntuWiki:UbuntuDevelopers|Ubuntu developer]] use the following [[UbuntuWiki:SponsorshipProcess|process]].  Also, if you need help deciding whether a package ought to be removed, please discuss on the `ubuntu-devel` mailing list rather than asking the archive administrators.
If you are not an [[UbuntuWiki:UbuntuDevelopers|Ubuntu developer]] use the following [[UbuntuWiki:SponsorshipProcess|process]].  If you are then subscribe the "ubuntu-archive" team to the bugs. If you need help deciding whether a package ought to be removed, please discuss on the `ubuntu-devel` mailing list rather than asking the archive administrators.
http://people.ubuntu.com/~ubuntu-archive/removals.txt has information on which packages were removed and why.
Refer to `https://launchpad.net/ubuntu/+source/<source package>` for the reason of the removal of a specific package.
[[Anchor(Architectures)]]
<<Anchor(Architectures)>>
==== Architectures ====
=== Architectures ===
Packages are typically built for each of several architectures.  For example, the `hello` package is built on `i386`, `amd64`, `sparc`, etc.  These are divided into two categories according to their level of official support by the project.
Packages are typically built for each of several architectures.  For example, the `hello` package is built on `i386`, `amd64`, etc.  These are divided into two categories according to their level of official support by the project.
===== Official Architectures =====
==== Official Architectures ====
These are officially supported and maintained by the Ubuntu project.  Canonical Ltd. provides server resources to build, store and distribute packages and installation media for them, and the core development team is responsible for their upkeep.  Build failures on these architectures are considered serious bugs.  Each official Ubuntu release and update includes appropriate support for these architectures.  There may or may not be a team which is specifically responsible for architecture-specific issues.  The kernel team builds and tests the Ubuntu kernel on these architectures.
These are officially supported and maintained by the Ubuntu project.  Canonical Ltd. provides server resources to build, store and distribute packages and installation media for them, and the core development team is responsible for their upkeep.  Build failures on these architectures are considered serious bugs.  Each official Ubuntu release and update includes appropriate support for these architectures.  There may or may not be a team which is specifically responsible for architecture-specific issues.  The kernel team builds and tests the Ubuntu kernel on these architectures.
* `i386`
* `i386`
* `amd64`
* `amd64`
* `sparc`
==== Ports ====
===== Ports =====
These are maintained on a best-effort basis by interested volunteers in the Ubuntu community.  Each architecture has a corresponding community team formed of the developers who support it.  Canonical Ltd. provides server resources to build, store and distribute packages and installation media for ports, however, the porting teams are responsible for their operation and maintenance, including the kernel, toolchain and build infrastructure.  Build failures are not considered a serious issue by the core team.  Ports may issue new releases or updates out of sync with official Ubuntu releases.
These are maintained on a best-effort basis by interested volunteers in the Ubuntu community.  Each architecture has a corresponding community team formed of the developers who support it.  Canonical Ltd. provides server resources to build, store and distribute packages and installation media for ports, however, the porting teams are responsible for their operation and maintenance, including the kernel, toolchain and build infrastructure.  Build failures are not considered a serious issue by the core team.  Ports may issue new releases or updates out of sync with official Ubuntu releases.
* `ia64` ([[UbuntuWiki:IA64PortStatus|IA64PortStatus]], https://launchpad.net/~ubuntu-ia64)
* `ia64` ([[UbuntuWiki:IA64PortStatus|IA64PortStatus]], https://launchpad.net/~ubuntu-ia64)
* `hppa` ([[UbuntuWiki:HPPAPortStatus|HPPAPortStatus]], https://launchpad.net/~ubuntu-hppa)
* `hppa` ([[UbuntuWiki:HPPAPortStatus|HPPAPortStatus]], https://launchpad.net/~ubuntu-hppa)
* `powerpc` (https://launchpad.net/~ubuntu-powerpc)
* `powerpc` (https://launchpad.net/~ubuntu-powerpc)
* `sparc`
* `lpia`
* `armel`
The ports system was announced here: https://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000040.html
The ports system was announced here: https://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000040.html
----
----
Go back to '''[[UbuntuWiki:UbuntuDevelopment]]'''.<br>
Go back to '''[[UbuntuWiki:UbuntuDevelopment|UbuntuDevelopment]]'''.<<BR>>
[[category:CategoryUbuntuDevelopment<br>CategoryProcess]]
[[category:CategoryUbuntuDevelopment<<BR>>CategoryProcess]]


[[category:UbuntuWiki]]
[[category:UbuntuWiki]]

2009年11月18日 (三) 21:12的最新版本

{{#ifexist: :UbuntuDevelopment/PackageArchive/zh | | {{#ifexist: UbuntuDevelopment/PackageArchive/zh | | {{#ifeq: {{#titleparts:UbuntuDevelopment/PackageArchive|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:UbuntuDevelopment/PackageArchive|1|-1|}} | zh | | }}

<<Include(UbuntuDevelopment/Header/Menu)>>

The Package Archive

All current official Ubuntu packages are stored in the master archive, which is widely mirrored. A search interface is available at [1]]. Old versions can be retrieved from [Launchpad. It is administered by the archive administration team. <<Anchor(Uploading)>>

Uploading

If you are not yet an official Ubuntu developer, you can arrange for your package to be uploaded via the SponsorshipProcess. Packages are uploaded via FTP to ftp://upload.ubuntu.com/ using `dput` or `dupload`. Notes for preparing your upload:

  • Make source-only uploads, i.e. use "``dpkg-buildpackage -S``"
  • When uploading to MOTU/Packages/REVU, please include the orig tarball as well (use parameters `-S -sa`)

When your upload is processed (typically within a matter of minutes), you will receive an email with the result of your upload, whether it succeeds or fails, unless you use an unregistered email address. The system will only send mail to an address which belongs to a launchpad account which is a member of the relevant team for uploading. E.g. motu for universe and ubuntu-core-dev for main. Your upload must be signed by a GPG key registered in Launchpad. If the signature cannot be traced to a member of the appropriate team, then the upload will be silently rejected. To add a new package to Ubuntu, simply upload it as usual. Any new packages uploaded are put in a queue to be checked by the administrators before being included. UbuntuDevelopment/Uploading has much more information about the topic. <<Anchor(Publishing)>>

Autobuilding and Publishing

Once an upload has been accepted, it takes some time to be [[UbuntuWiki:[Autobuilders|built]]] and published in the archive. For simple packages, this is usually on the order of an hour, but varies depending on release activity (uploads may be temporarily suspended), the time needed to build the package (including other packages in the build queue), and other factors. After a package has been built, the next publisher run that starts at three minutes past each hour will process it, usually finishing towards the end of that hour; at the end of that process it will be visible in the public archive. <<Anchor(Notification)>>

Notification of changes

Notifications of uploads are sent to a mailing list. A different list is used for each Ubuntu release:

Changelogs for all packages are available at http://changelogs.ubuntu.com/changelogs/ (this is the source used by update-manager and Synaptic). <<Anchor(SyncingAndMerging)>>

Syncing and Merging

(See the ReleaseProcess#MergeProcess rationale.) Most packages in Ubuntu originate elsewhere, including Debian and related package repositories. A sync copies a source package verbatim from an external repository into Ubuntu, overwriting any package of the same name. This is used when a newer version of it is available, and should be included in Ubuntu, and happens automatically during some phases of the release cycle. To request a sync, follow the SyncRequestProcess. A merge is a three-way merge of a package which originated in an external repository. This is used when there is a newer version available from the external repository, but the package has also been modified (branched) in Ubuntu. the Merging page explains how and when to merge. Packages which are maintained in Bazaar can and should be merged using Bazaar itself. The "Last Uploader" column in the Merge-o-Matic output is the default assignee for the merge, following the touched-it-last maintenance principle. However, you can and often should grab other people's merges if they don't have time or you feel you can do a better job. It's polite and often a good idea (though not mandatory) to contact the other person first to make sure you aren't duplicating work. Backports work similarly to syncs, but have somewhat different requirements. To request a backport, follow the UbuntuBackports process. <<Anchor(Consistency)>>

Consistency

The archive is periodically checked for various inconsistencies, such as incorrect dependency relationships between packages.

A special case is the installer:

  • The `Kernel-Version:` field in the `installer` file in all the seeds needs to be current.
  • It needs to be built against the current kernel. This can be checked on the karmic installer's udeb list (please also verify the other architectures).

<<Anchor(Freezes)>>

Freezes

Freezes are restrictions on which changes can be uploaded in order to try and stabilize Ubuntu for release. There are various different freezes that happen at different times in the cycle, and they are of different types, affect different packages, and have different procedures for uploading during them, so understanding them all can be difficult. You can see which freezes happen and when on the ReleaseSchedule, and each is linked to a page about that particular freeze, so that is a great place to go for the information. This page will provide a bit more explanation about the types of freezes and how to handle them. Freezes are generally also announced on ubuntu-devel-announce, so subscribing to that can keep you up-to-date. However, there aren't reminders about upcoming freezes posted to that list, so keep on top of which freezes are upcoming will help you to meet the deadlines in your work.

Uploading Restrictions

There are two ways that freezes are enforced, which are known as "soft" and "hard" freezes. Knowing whether a particular freeze is soft or hard is important, as it will allow you to know what effect uploading will have, and who needs to be aware of changes that you make for them to be included.

Soft Freezes

Soft freezes have no mechanism in the archive software to enforce them, they just rely on each developer to ensure that they only upload appropriate changes. For instance, FeatureFreeze is a soft freeze, as you can still upload as before, you are just required to seek exceptions for new features. Most importantly, freezes for the alpha releases of Ubuntu are soft freezes. This means that nothing will prevent your changes from entering the archive, so you must ensure that they don't interfere with the process of releasing the alpha. See the section on milestone freezes later for more information on what this means.

Hard Freezes

In contrast to soft freezes hard freezes flick a switch in the archive software such that all uploads are not immediately accepted, they instead end up in the UNAPPROVED Queue. Packages remain in this queue until they are explicitly accepted by an Archive Administrator. This means that your changes can be reviewed before they are accepted, so that extra review can be done, and it is not left to your discretion to enforce the rules of the freeze. While this could mean that you could upload with less care, it is not wise to, as those who can review are generally very busy at this time already, and extra work at these crucial periods is not appreciated. It is generally a good idea to ensure that someone on the release team knows that you will be making an upload to fix the particular issue before you do so (fixing a release critical bug is generally permission enough). <<Anchor(Components)>>

Managing Components

Ubuntu packages are classified into components according to maintenance and licensing criteria, a process which is described in SeedManagement. Packages sometimes move from one component to another, according to policy or licensing changes, as managed by the archive administrators. Special consideration is necessary when packages move into `main` or `restricted`, as this implies a commitment of ongoing maintenance. Such changes must follow the MainInclusionProcess. <<Anchor(Autobuilders)>>

Autobuilders

Ubuntu source packages are automatically built for a variety of platforms by Launchpad, which provides build status information. Build log files are available from Launchpad as well, by searching for the package and selecting a version. Some supplementary information about the build infrastructure is available on BuildDaemons. <<Anchor(Removals)>>

Removing Packages

Packages which are removed from Debian are semi-automatically removed from Ubuntu universe on a regular basis by the administrators. However, packages are not removed from Ubuntu main without explicit request, nor are packages which originated elsewhere. To request removal of such a package, file a bug against the package. The bug must have the following elements:

  • which release to remove it from (e.g., `hardy`)
  • whether to remove both the source package and all binary packages
  • a rationale for why they should be removed
  • confirmation that the binary packages have no rdepends (no other package depends on them)

If you are not an Ubuntu developer use the following process. If you are then subscribe the "ubuntu-archive" team to the bugs. If you need help deciding whether a package ought to be removed, please discuss on the `ubuntu-devel` mailing list rather than asking the archive administrators. Refer to `https://launchpad.net/ubuntu/+source/<source package>` for the reason of the removal of a specific package. <<Anchor(Architectures)>>

Architectures

Packages are typically built for each of several architectures. For example, the `hello` package is built on `i386`, `amd64`, etc. These are divided into two categories according to their level of official support by the project.

Official Architectures

These are officially supported and maintained by the Ubuntu project. Canonical Ltd. provides server resources to build, store and distribute packages and installation media for them, and the core development team is responsible for their upkeep. Build failures on these architectures are considered serious bugs. Each official Ubuntu release and update includes appropriate support for these architectures. There may or may not be a team which is specifically responsible for architecture-specific issues. The kernel team builds and tests the Ubuntu kernel on these architectures.

  • `i386`
  • `amd64`

Ports

These are maintained on a best-effort basis by interested volunteers in the Ubuntu community. Each architecture has a corresponding community team formed of the developers who support it. Canonical Ltd. provides server resources to build, store and distribute packages and installation media for ports, however, the porting teams are responsible for their operation and maintenance, including the kernel, toolchain and build infrastructure. Build failures are not considered a serious issue by the core team. Ports may issue new releases or updates out of sync with official Ubuntu releases.

The ports system was announced here: https://lists.ubuntu.com/archives/ubuntu-announce/2005-October/000040.html


Go back to UbuntuDevelopment.<
> [[category:CategoryUbuntuDevelopment<
>CategoryProcess]]