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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111002103726.GA14294@elie