On Tue, Sep 14, 2004 at 10:36:13PM -0400, Stephen Gran wrote: > I kind of think the upload is already the 'signing off' (why would you > upload something you didn't think would work? - not that it doesn't > happen, but you see my point), but I tend to agree here - a higher > standard should be enforced. I am not sure how to enforce this without > making a lot more work for the RM's, though. I'm not saying that you're signing off on the claim that *your* package will work. I'm saying that your upload won't break other packages that *depend* on your package. Or, in the event that you do break compatibility with the old version, you've worked with the maintainers of whichever packages depend on your to insure that they will also make updates to their packages to maintain compatibility. > I like it. I think making the dependencies go into volatile won't work, > however - I am thinking of one of my packages here. clamav-milter uses > libmilter - does this put all of sendmail into volatile? Same source > package, after all. And at the lower level, of course, there's libc > :) Or am I missing something, and you mean 'dependencies' not in > the packaging sense, but in the databases used for those programs or > something? You're thinking about it the other way around. ClamAV depends on milter. A change in ClamAV doesn't necessitate a change in milter. OTOH, if some package out the depends on ClamAV, then you'll need to do work to make sure that package will continue to work. Since that package may need an update to match some change in ClamAV, that package must also go into the volatile section. It's similar to e.g. the contrib section in that regard. Any packages that itself depends on a package in contrib must also go in contrib. I hope that clarifies things a bit for you. 8^) noah
Attachment:
pgpLn2elf4xjC.pgp
Description: PGP signature