Re: On Sid and Experimental
Hiya,
Manjul Apratim wrote:
> I cannot help but view too many apt pins
> as an intentional recipe for disaster!
If you really want to experience life on the edge, you can try this:
echo 'APT::Default-Release "experimental";' \
>/etc/apt/apt.conf.d/preferexperimental.conf
Used in combination with apt-listbugs, the result generally pretty
pleasant and stable.
To piggy-back on what Martin said: the current suites all have release
management roles. See the suite update policy at
<http://release.debian.org/> for an overview.
stable:
the released OS distribution, which has received a lot of QA
work. Does not change except at point releases (every few
months) and major release (every couple of years or so).
stable-proposed-updates:
where the next minor update of stable cooks. People prepare
packages for here directly, and although the individual fixes
that get used are tested in unstable first, the reliability of
the final packages is mostly due to code review.
testing:
where the next major update of stable cooks. No package
should be missing dependencies, except occasionally when needed
to get through a transition. Packages come from unstable (with
a few exceptions) and get tested there first. The purpose of
the testing suite is to make sure packages work well together
and can function as a coherent distribution.
unstable:
where packages for testing get built and initially tested. No
package enters here unless the package maintainer is confident that
it or some later version will be suitable for the next stable
release. Build-time dependencies of packages in unstable are taken
from unstable, so maintainers exercise care before updating
ABI-incompatible new versions of libraries here --- and (at least in
simple cases) when library ABI changes happen, related packages get
rebuilt and accumulate here before they can move all at once to
testing. Nevertheless, unstable can be a site of rapid change. It
is normal for packages in unstable to be missing dependencies that
have not been built or uploaded yet.
experimental:
where packages are uploaded when either (a) they should not be
uploaded to unstable to avoid disrupting an ongoing interface
transition or (b) they are not ready for upload to unstable for some
other reason (maybe they need more testing before reaching a large
audience).
Much of GNOME 3 falls in category (a) --- these packages are moving
from experimental to unstable in small, coherent batches so they can
migrate to testing more efficiently.
If I understand its goals correctly, CUT would also play a release
management role. In addition to making it easier for people to test
that packages in testing work well together, it could provide the
raw material for making pre-releases of the next version of the
installation media.
Hope that clarifies a little.
Jonathan
Reply to: