On Mon, Jun 18, 2001 at 11:29:15PM -0300, Peter Cordes wrote: > If mailcrypt can be installed and do useful stuff without any > packages from non-free installed, then it should itself be in main, > shouldn't it? yup, but only if it stops depending on pgp. (right now it depends on gnupg|pgp|pgp5) > What would happen in a similar situation where all packages involved > were already in main? Someone else pointed out that we should think > about the general case of this problem, and have a way to deal with > it. The fact that mailcrypt is currently in contrib lets us sort of > wriggle out of the problem, in this specific instance of the problem. > Does proposed-updates get merged when new sub-releases (e.g. r3) are > made? If so, then putting packages there does it. If not, then the > updated packages that the new security-fix package depends on must > become part of potato somehow. each package in proposed-updates gets merged into the next stable revision provided they are approved by the release manager. just because something is placed in proposed-updates does NOT guarentee it will go into stable by any means. many packages are rejected every time. right now it pretty much has to fix a security hole to go into stable, or else fix a grave or critical bug. (read the package in stable is 100% broken and useless, the proposed update fixes that). > IMHO, security fixes should still go into security.d.o ASAP, without > waiting for packages that depend on them to be updated, but those > packages _do_ need to be updated. unless the package it depends on is somewhat important, say libc as a rediculous example. as a sidenote this is exactly why debian backports security fixes rather then just installs new upstream versions. new upstream versions almost invariable break SOMETHING (we went through this when debian decided backporting all of bind's patches was too much trouble and installed a new upstream bind) gnupg is an exception since upstream is already only making security fixes (mainly..) to the 1.0.x tree anyway. probably also because gnupg is very complex and backporting could cause more trouble then it solves. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpch_l6xblzn.pgp
Description: PGP signature