mozilla dependencies and versioned conflicts

[Steve Langasek]

--b0op/nKJ9CeIhp9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, May 22, 2005 at 10:39:50AM +0200, Mike Hommey wrote:
> > It looks like the security-fix-only new upstream version of mozilla, 1.=
7.8,
> > has blocked again on kazehakase and enigmail (and probably on locale
> > packages, but I haven't gotten there yet) because the sarge versions of
> > these packages conflict with mozilla-browser (>=3D 2:1.7.8).

> > The solution offered by kazehakase in unstable is a new upstream versio=
n.

> > $ debdiff k/kazehakase/kazehakase_0.2.{6-2,7-1}.dsc | wc -l
> >   25040
> > $=20

> > And for enigmail, there currently is no solution available, other than
> > removing the package from sarge.

> > Remember, mozilla-browser 1.7.8 was a *security fix*.  There should not=
 be
> > any changes in that upload which affect kazehakase or enigmail, AFAICT,=
 yet
> > the way the package relationships are structured leaves no option other
> > than a re-upload of all dependent packages whenever a new upstream vers=
ion
> > comes out.  The release team has been doing the necessary fiddling to g=
et
> > these packages into testing every time, but now that we're in a freeze =
it's
> > particularly ugly to do this.

> > I've approved kazehakase 0.2.7-1 to go into sarge, but I'm not happy ab=
out
> > doing so.  There really must be a better answer for mozilla dependency
> > handling, mustn't there?  What can we do to track the actual exported
> > interfaces required by these packages, so that this isn't an issue agai=
n for
> > etch?

> Note kazehakase 0.2.7-1 still conflicts with mozilla-browser 1.7.8
> (looking at its control file)...

<sigh>

Right you are.

So, given the choice between leaving this security hole in sarge longer and
dropping kazehakase, I'm going to kick kazehakase out of testing as well. :/
Unless the maintainer can get a fixed package uploaded to t-p-u in the next
18 hours or so, that is.

> The issue is not really a mozilla issue, only an indirect one.

> Usually, minor version updates of mozilla do break stuff, so packages
> built against mozilla added conflicts so that they're not stuffed by
> mozilla next upload.

> This time, the version update is supposed to be security only, and not
> to break stuff. Thus, theorically, just changing the Conflicts: in the
> control file is enough to have these programs depending on
> mozilla-browser be able to use the security fix release.

> Note that I didn't follow 1.7.8 release, so I'm just assuming from
> theory, maybe 1.7.8 broke stuff...

The question is, how can we be proactive about identifying the classes of
changes that do or don't break these packages, so that mozilla can be
checked for compatibility at the time of upload instead of having kazehakase
and enigmail update their conflicts: after the fact?

--=20
Steve Langasek
postmodern programmer

--b0op/nKJ9CeIhp9z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD4DBQFCkEpLKN6ufymYLloRAlupAJiPmxAuYZpCPJUX+ZnoNq8mwYoxAKCo4GY+
abc3Q9lNW96A0n8EMw2tdQ==
=RP0K
-----END PGP SIGNATURE-----

--b0op/nKJ9CeIhp9z--