Debian Packages Cycle : Package maintenance

Each Debian software package has a maintainer who keeps track of releases by the "upstream" authors of the software and ensures that the package is compliant with Debian Policy, coheres with the rest of the distribution, and meets the standards of quality of Debian. In relations with users and other developers, the maintainer uses the bug tracking system to follow up on bug reports and fix bugs. Typically, there is only one maintainer for a single package, but increasingly small teams of developers "co-maintain" larger and more complex packages and groups of packages.^[41]

Periodically, a package maintainer makes a release of a package by uploading it to the "incoming" directory of the Debian package archive (or an "upload queue" which periodically batch-transmits packages to the incoming directory). Package uploads are automatically processed to ensure that they are well-formed (all the requisite files are in place) and that the package is digitally signed by a Debian developer usingOpenPGP-compatible software. All Debian developers have public keys.^[42] Packages are signed to be able to reject uploads from hostile outsiders to the project, and to permit accountability in the event that a package contains a serious bug, a violation of policy, or malicious code.

If the package in incoming is found to be validly signed and well-formed, it is installed into the archive into an area called the "pool" and distributed every day to hundreds of mirrors worldwide. Initially, all package uploads accepted into the archive are only available in the "unstable" suite of packages, which contains the most up-to-date version of each package.

However, new code is also untried code, and those packages are only distributed with clear disclaimers. For packages to become candidates for the next "stable" release of the Debian distribution, they first need to be included in the "testing" suite. The requirements for a package to be included in "testing" is that it:^[43][44]

• Must have been in unstable for the appropriate length of time (the exact duration depends on the "urgency" of the upload)
• Must not have a greater number of "release-critical" bugs filed against it than the current version in testing. Release-critical bugs are those bugs which are considered serious enough that they make the package unsuitable for release.
• Must be compiled for all release architectures the package claims to support (eg: the i386-specific package gmod can be included in "testing")
• All of its dependencies must either be satisfiable by packages already in testing, or be satisfiable by the group of packages which are going to be installed at the same time.
• The operation of installing the package into testing must not break any packages currently in testing.

Thus, a release-critical bug in a package on which many packages depend, such as a shared library, may prevent many packages from entering the "testing" area, because that library is considered deficient.

Periodically, the Release Manager publishes guidelines to the developers in order to ready the release, and in accordance with them eventually decides to make a release. This occurs when all important software is reasonably up-to-date in the release-candidate suite for all architectures for which a release is planned, and when any other goals set by the Release Manager have been met. At that time, all packages in the release-candidate suite ("testing") become part of the released suite ("stable").

It is possible for a package – particularly an old, stable, and seldom-updated one – to belong to more than one suite at the same time. The suites are simply collections of pointers into the package "pool" mentioned above.

[edit]Security information and policy

The Debian Project, being free software, handles security policy through public disclosure rather than through security through obscurity. Many advisories are coordinated with other free software vendors and are published the same day a vulnerability is made public. Debian has a security audit team that reviews the archive looking for new or unfixed security bugs. Debian also participates in security standardization efforts: the Debian security advisories are compatible with the Common Vulnerabilities and Exposures (CVE) dictionary, and Debian is represented in the Board of the Open Vulnerability and Assessment Language (OVAL) project.^[45]

The Debian Project offers extensive documentation and tools to harden a Debian installation both manually and automatically.^[46] SELinux(Security-Enhanced Linux) packages are installed by default though not enabled.^[47]

Source : wikipedia.org

Bootloader Karmic Koala with Grub2

Today I have finished installing karmic koala, at menu loader many option to log in, and than I thing to remove some loader.

First I go to : /boot/grub/menu.lst , but viola... i cant that at my karmic koala. after googling I can find the problem, the last version of ubuntu use Grub v1 and for ubuntu karmic koala user Grub v2.

what is basicly different between Grub v1 and Grub v2?

• menu.lst no longer controls the menu.

• 'grub.cfg` is now in control of the menu.

• grub.cfg is automatically generated by one of the GRUB 2 scripts.

• The partition numbering is different.

• Stanzas are phrased slightly differently and can't be copied directly from a GRUB 1 menu.lst to grub.cfg. They are pretty close and easy to change, though.

So according to manual from grub v2, i can edit my loader Ubuntu Karmic with : /boot/grub/grub.cfg

### BEGIN /etc/grub.d/10_linux ###
menuentry "Ubuntu, Linux 2.6.31-19-generic" {
recordfail=1
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
set quiet=1
insmod ext2
set root=(hd0,10)
search --no-floppy --fs-uuid --set fa5dfed6-faa4-43b5-b0a9-6b3f623706f9
linux /boot/vmlinuz-2.6.31-19-generic root=UUID=fa5dfed6-faa4-43b5-b0a9-6b3f623706f9 ro quiet splash
initrd /boot/initrd.img-2.6.31-19-generic
}
menuentry "Ubuntu, Linux 2.6.31-19-generic (recovery mode)" {
recordfail=1
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
insmod ext2
set root=(hd0,10)
search --no-floppy --fs-uuid --set fa5dfed6-faa4-43b5-b0a9-6b3f623706f9
linux /boot/vmlinuz-2.6.31-19-generic root=UUID=fa5dfed6-faa4-43b5-b0a9-6b3f623706f9 ro single
initrd /boot/initrd.img-2.6.31-19-generic
}
menuentry "Ubuntu, Linux 2.6.31-14-generic" {
recordfail=1
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
set quiet=1
insmod ext2
set root=(hd0,10)
search --no-floppy --fs-uuid --set fa5dfed6-faa4-43b5-b0a9-6b3f623706f9
linux /boot/vmlinuz-2.6.31-14-generic root=UUID=fa5dfed6-faa4-43b5-b0a9-6b3f623706f9 ro quiet splash
initrd /boot/initrd.img-2.6.31-14-generic
}
menuentry "Ubuntu, Linux 2.6.31-14-generic (recovery mode)" {
recordfail=1
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
insmod ext2
set root=(hd0,10)
search --no-floppy --fs-uuid --set fa5dfed6-faa4-43b5-b0a9-6b3f623706f9
linux /boot/vmlinuz-2.6.31-14-generic root=UUID=fa5dfed6-faa4-43b5-b0a9-6b3f623706f9 ro single
initrd /boot/initrd.img-2.6.31-14-generic
}
## END /etc/grub.d/10_linux ###

and change to :

### BEGIN /etc/grub.d/10_linux ###
menuentry "Ubuntu, Linux 2.6.31-19-generic" {
recordfail=1
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
set quiet=1
insmod ext2
set root=(hd0,10)
search --no-floppy --fs-uuid --set fa5dfed6-faa4-43b5-b0a9-6b3f623706f9
linux /boot/vmlinuz-2.6.31-19-generic root=UUID=fa5dfed6-faa4-43b5-b0a9-6b3f623706f9 ro quiet splash
initrd /boot/initrd.img-2.6.31-19-generic
}
menuentry "Ubuntu, Linux 2.6.31-19-generic (recovery mode)" {
recordfail=1
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
insmod ext2
set root=(hd0,10)
search --no-floppy --fs-uuid --set fa5dfed6-faa4-43b5-b0a9-6b3f623706f9
linux /boot/vmlinuz-2.6.31-19-generic root=UUID=fa5dfed6-faa4-43b5-b0a9-6b3f623706f9 ro single
initrd /boot/initrd.img-2.6.31-19-generic
}
## END /etc/grub.d/10_linux ###

After do that we can reboot our Ubuntu and just look different view while boot loader menu shown.