A brief overview of stability levels and automatic submission
Ebuild stability (status) levels.
The "new" status actually combines "new", "approved-new" and "core-new"
levels. Second is for new core developer submissions and 3rd is for new
submissions or updates of core packages.
||A newly submitted ebuild. Can be installed/considered by emerge
only if --enable-all option is given in command line or Stability_level
flag in make.conf is set to All
||This is for ebuilds not reviewed by core group but which have
reached certain threshold of positive votes. Is seen by emerge if
--enable-confirmed is given or Stability_level=confirmed.
||ebuilds reviewed and approved by core group (and received
sufficient amount of positive votes). Requires Stability_level of
"approved" or --enable-approved in command line (last one atypical, as
Stability_level wil rarely if ever be set higher).
||System libraries and other crytical packages (likely including
portage scripts). Requires core developer attention. No submissions go
directly into CVS. Awailable always, as this is maximus stability level
that can be specified.
||Packages whose average vote dropped below negative threshold value
or that were reviewed but not approved by core developers. These packages
are effectively banned form consideration by high level tools (think
present masked packages). In order to be installed require invocation of
low level ebuild utility.
It may not be necassary to consider
such submissions as new but rather to assign them appropriate status
immediately. However maintaining overal procedure for developer and core
submission (namely vote-count before confirmation) will allow for a more secure
distribution if there is a need for such (you don't put the latest two-day old
kernel version on a production sever after all. Instead you normally wait some
time and observe comments of must-have-latest community. kernel-2.4.15 was a
good example of how things can go wrong (even in a stupid way) on just any
On the other hand this distinction is largely conceptual and requires special
measures (such as core and approved package lists) only on server. User tools
only need to know about the "new" status. All the threshold values, urgency and
other politics happens on CVS.
It is possible to have an additional Stability_level setting of "unstable" to
let high level tools access ebuilds marked "unstable".
I don't think this is a good idea though, as certain people won't be able to
hold the temptation to break their system :-).
But then rsync_Stability_Level should have such setting
available, so that people could see what ebuilds were worked on. Somebody might
actually repair it!
Automated submission and server sequrity.
- Automation in limited area:
Automated ebuild submissions are allowed only under /usr/portage
omitting all "system" subdirectories such as profiles/ ...
- Protect core packages:
Core packages cannot be modified: no submission is allowed if it tries
to touch directory marked as containing core package.
- No overwrite rule:
No files shell be overwritten (otherwise submission is rejected). All
changes shell be submitted as a new -rX ebuild (the same for supporting files).
- Author discipline.
Author shell take care to prepare all necessary files even if they are
trivial to generate. Submission is not checked for consistency and will likely
be marked "unstable" when users discover that it does not work.
post a message to gentoo-dev mailing list, or use my