On Mon, Dec 20, 2010 at 11:48:20AM +0100, Bill Allombert wrote: > On Sun, Dec 19, 2010 at 06:09:58PM -0500, Roberto C. Sánchez wrote: > > On Sun, Dec 19, 2010 at 07:30:48PM +0100, Bill Allombert wrote: > > Please see #601977 and let me know if you still feel the same way. > > The correct fix for #601977 is for > cyrus-sasl2-mit-dbg and cyrus-sasl2-heimdal-dbg to Replaces: cyrus-sasl2-dbg. > Neither Pre-depends nor Conflicts, nor adding more Depends are going to fix > it. > Well, since the user must have cyrus-sasl2-dbg installed along with one of either cyrus-sasl2-mit-dbg or cyrus-sasl2-heimdal-dbg, I don't see either package reasonably replace cyrus-sasl2-dbg. The only way that would be possible would be to duplicate the files from cyrus-sasl2-dbg into both cyrus-sasl2-mit-dbg and cyrus-sasl2-heimdal-dbg, which doesn't seem like a good idea either.
> > Basically, the dependency from cyrus-sasl2-dbg is on > > "cyrus-sasl2-mit-dbg | cyrus-sasl2-heimdal-dbg", while the two specific > > -dbg packages depend on the main package. Basically, if a user > > installs the cyrus-sasl2-dbg, we want them to also get the specific > > symbols for one of MIT or Heimdal. > > How do you know the user will get the right one ? If the user can get the > wrong one, > then what is the point ? > It doesn't matter to us one way or the other. There is no "wrong one." If the user has the MIT version of the library installed, then the MIT debug symbols are "right" and if the user has the Heimdal version of the library installed then the Heimdal debug symbols are "right." > > This also takes care of a bug in the > > Lenny -> Squeeze upgrade process (reported in #601977). > > It does not. Only Replaces can do that. > > > However, if the > > user goes the route of installing either cyrus-sasl2-mit-dbg or > > cyrus-sasl2-heimdal-dbg, then we also need to make sure that they get > > the common -dbg symbols. > > In that case cyrus-sasl2-dbg should have been called cyrus-sasl2-common-dbg > and not depend > on anything. > The release team was already not keen on accepting a new binary package. I have a feeling that two new binary packages may have posed a problem. I suppose that it would be possible to create a package called cyrus-sasl2-common-dbg as you suggest. Then cyrus-sasl2-dbg would be a dummy package depending on cyrus-sasl2-common-dbg and cyrus-sasl2-mit-dbg. If the release team would be willing to accept a new version of the package to fix this bug, then I would be happy to prepare an upload. However, since we are in deep freeze at this moment, I think that the release team would need to be convinced that this bug is RC. Could you raise the issue with them? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
signature.asc
Description: Digital signature
