No, but you can do, like you said, and deny them a new package unless they take up an older one that matches thier area of expertiece. For example, (still picking on CDRToaster as an example only at this time) if I were the maintainer of mkisofs, and I updated it, thus breaking CDRTOaster. then a month or two later I wanted to add a new package that debian allready has a functional equivilant of, the maintainer coordinator (does such a person exist?) would look and see that CDRToaster is DOA upstream, and it's pakager hasn't marked it as such and either retired it, or replaced it with another package, then the mkisofs maintainer would be asked to adopt the CDRToaster if they had the capability to do so. Now, this is just a theoretical situation, so take it with a grain of salt and look more at the idea behind the theory. :) Not saying it's THE solution, just an idea of how to keep people from leaving cruft all over, and encouraging maintainers to check up on packages that require/strongly-reccomend thier package that they updated. (note, this obviously can't be applied to core packages very realisticly, just for optional/fringe stuff thats poping up) On Wed, Dec 26, 2001 at 04:22:42PM -0600, Nathan E Norman wrote: > On Wed, Dec 26, 2001 at 03:49:11PM -0600, Brian Wolfe wrote: > > Instead of many new packages, why not make people pick up the orphaned > > stuff, and find replacements or adopt packages that have been DOA upstream? > > In a volunteer organization, you can't _make_ people do anything. You > can encourage them to do things, or forbid them from doing things, but > you can't say "Hey Hans, you need to do this project, and Bill needs > to do that project". Corporations work that way, Debian does not. > > -- > Nathan Norman - Staff Engineer | A good plan today is better > Micromuse Ltd. | than a perfect plan tomorrow. > mailto:nnorman@micromuse.com | -- Patton -- -------------------------------------------------------------------------------- TerraBox.com Fingerprint: 2849 5090 D4E0 2A6C C648 A750 52F8 8504 67DB 205C
Attachment:
pgpbsKyWExAAk.pgp
Description: PGP signature