Gentoo Linux Portage Development
1. Project Description
The Portage Development Project works to provide a continuously
expanding and developing tool for the management and installation
of packages. The developers work on providing a coherent system
that is as trouble free as possible (backwards compatible, automated,
and simple). Bugs are tracked and fixed from the
Gentoo bug tracker and
developer-developer correspondence is maintained on the
gentoo-portage-dev mailing list. Another communication channel is
the #gentoo-portage IRC channel on the freenode network.
2. Project Goals
The goal of the Portage Development Project stands at providing
a seamless integration of developer and user tools to aid the growth
and maintenance of the Gentoo Portage Tree.
3. Developers
Developer |
Nickname |
Role |
Jason Stubbs |
jstubbs |
Lead |
Marius Mauch |
genone |
Lead |
Simon Stelling |
blubb |
Contributor |
Emanuele Giaquinta |
exg |
Contributor ( Prefix branch ) |
Kito Danya Dietrich |
kito |
Contributor ( Prefix branch ) |
Alec Warner |
antarus |
Member ( Documentation ) |
Ned Ludd |
solar |
Member |
Mike Frysinger |
vapier |
Member ( Documentation ) |
Zach Medico |
zmedico |
Member ( Release Coordinator ) |
Members from subproject
Portage Sandbox |
|
|
Martin Schlemmer |
azarah |
Lead |
Brian Harring |
ferringb |
Member |
Members from subproject
Gentoo Portage Tools |
|
|
Marius Mauch |
genone |
Lead ( glsa-check ) |
Paul Varner |
fuzzyray |
Member ( gentoolkit ) |
Karl Trygve Kalleberg |
karltk |
Member ( gentoolkit ) |
Harald van Dijk |
truedfx |
Member ( ufed ) |
All developers can be reached by e-mail using nickname@gentoo.org.
4. Subprojects
The Portage
project has the following subprojects:
Project |
Lead |
Description |
Portage Sandbox
|
Martin Schlemmer |
The Portage Development Sandbox Project is devoted to maintaining and updating the portage sandbox library. |
Repoman |
|
The maintenance of the repoman tool. Repoman provides the
checking and commit services necessary to ensure that ebuilds are
proper before entering into circulation.
|
Documentation |
Mike Frysinger |
Updating and Creating documentation for the tools of Portage.
|
Gentoo Portage Tools
|
Marius Mauch |
The Tools subproject deals with portage related tools that are not included in the core portage package. This covers maintaining ebuilds for external packages as well as developing and improving our own utilities and scripts. |
5. Resources
Resources offered by the
Portage
project are:
6. External Documentation Resources
Unless otherwise noted the following resources are maintained by the documentation project,
but as they are the primary online documentation for portage we will list them here.
7. Contributing to Portage
Bug Reports
Please report all bugs you encounter on
our bug tracking system.
Before opening a new bug report please make sure that the bug has not
already been reported by another user.
Important: Do not report bugs/requests about anything other than sys-apps/portage in the Portage Development product |
In your bug report please state clearly:
- How you triggered the bug (commands executed, files edited, ...)
- What portage version you used when you found the bug
- If the bug is reproducable
- The output of the emerge --info command
Please don't get too impatient if there is no immideate reaction on your bug,
it can sometimes take a while before a developer has time to look at it (this
also applies to non-Portage bug reports). Often we'll need additional information
from you while trying to resolve a bug, please provide it as soon as you can, if we
have to wait too long (over a month) we'll likely close the bug as RESOLVED:NEEDINFO,
you can however reopen it when you posted the requested information.
Please do not reopen bugs unless you're in one of the following situations:
- The bug was marked as RESOLVED:FIXED, but you can still reproduce it with the new
version that is suposed to contain the fix (the version is generally stated when
the bug is closed)
- The bug was marked as RESOLVED:NEEDINFO and you have provided the requested information
- The bug was marked as RESOLVED:WONTFIX, RESOLVED:CANTFIX or RESOLVED:LATER
and you think we misunderstood you. Do not reopen a bug just because you disagree
with our resolution.
Be aware that we will still read comments on bug reports even if the report itself is closed,
so you don't have to reopen it just to get our attention.
Every bug report deals with one specific problem, please respect that and don't talk about
other not directly related bugs on a bug report.
Submitting Patches
If you want to submit a patch to sys-apps/portage or a related package, please make
sure the patch follows these criteria:
- Use TABS. Some people like 8 spaces, some people like 4, and some
like 2. Tabs are the happy medium. Patches that use spaces and/or a mix of
tabs and spaces for indentation will likely be rejected.
- Generally submit diff files instead of whole files, only when the diff is
significantly larger than the file itself or the file didn't exist previously
submitting the whole file is acceptable.
- Diffs have to be in unified form (diff -u, svn diff).
- Always submit a detailed explanation of what the patch does and, if necessary,
why you chose the specific implementation you submitted (IOW: what's the
benefit of the patch). Also include any problems and/or drawbacks you think the patch has.
- Always state against which version (for releases) or revision and branch (for svn patches)
the patch was made.
- Only submit clean patches. Do not include other patches in a
submitted patch. If the code found in a patch does not match the
description of the patch, it will be rejected. Also don't add any unrelated code cleanups
in your patch
If the patch is related to a specific bug report, please attach it there as text/plain.
If it is not directly related to a bug report (to your knowledge) please send it to the
gentoo-portage-dev mailing list and tag the subject with '[PATCH]'.
Note: Patches for packages NOT related to sys-apps/portage go on
http://bugs.gentoo.org, please do not send them to the gentoo-portage-dev
mailing list |
Access to Portage SVN repositories
The Portage sourceode is maintained within a SVN repository on the Gentoo SVN server.
This server is only accessible for Gentoo developers, it doesn't offer anonymous access.
If you are a dev: The main repository is located at svn+ssh://cvs.gentoo.org/var/svnroot/portage/main,
please note that it is subject to strict access controls, only people listed
in the developers section on this page are able to commit to it.
Note: It is assumed you know how to work with Subversion. |
The repository currently contains the following branches:
- trunk: the current main development line based on the 2.0 codebase
- branches/2.1-experimental: the former development line, now abandoned (don't use it unless you want to backport stuff)
- branches/prefix: experimental branch with support for prefix installs
- branches/2.0.54: stable maintenance branch
Note: The old CVS repository still exists, but is not updated anymore or used in any other way. |
Note: The saviour branch is no longer an official Gentoo project and is hosted offsite. The savior branch is now
located at http://gentooexperimental.org/~ferringb/bzr/saviour. The saviour branch requires
bzr. |
8. Project tasks
name |
description |
main contact |
references |
comments |
Elog integration |
Development of a modular ebuild logging facility and integration of it into portage |
genone |
bug 11359 |
included in >=portage-2.1_pre1 |
Prefix support |
Adding support to portage to install packages into alternate locations |
kito |
- |
- |
Portage rewrite (savior branch, aka bcportage) |
A new portage API based on object oriented python |
ferringb / marienz |
- |
started in September 2005 |
Confcache |
Add a cache to ./configure scripts to reduce build times |
ferringb |
- |
included in >=portage-2.1_pre5 |
Cache subsystem rewrite |
A new implementation of the portage metadata cache |
ferringb |
- |
finished in Dec 2005, included in >=portage-2.1_pre1 |
metascan integration |
Adding the metascan and auxget tools to portage |
genone |
Forum thread regarding metascan |
- |
Portage GPG signing and verification |
Refactor signing code in portage to enable developers to sign all content in the portage tree. |
antarus |
- |
Started in Jan 2006 |
Repoman rewrite |
Rewrite repoman to cover the entire tree and make it more modular, also write a server version to generate reports on a regular base |
antarus |
- |
started in January 2006 |
Manifest2 support |
Implementing a new format for package manifests and digests to replace the current system |
genone |
GLEP 44 |
- |
|