Adeodato Simó wrote:
* Steve Langasek [Sun, 21 Nov 2004 02:47:35 -0800]:KDE 3.3 in sarge is contingent on the KDE maintainers being able to provide the same sort of assurances that were asked of the GNOME maintainers regarding the safety of allowing these packages to trickle in (i.e., the correctness of the package relationships), which calls for comprehensive partial upgrade testing.I have mixed feelinks when wrt 'partial upgrade testing' in KDE. we know from experience that KDE upstream really ensures that their monolithic x.y.z works together nicely, but that mixing even minor point releases can break things very badly.
In that case, you should be using the control files to prevent mixed installs. If users can install packages in some combination that won't work; the Depends/Recommends/Provides/Conflicts fields should be used to tell them of that in advance. That's what they're for.
There's no point having mixed feelings about this: it's something that can be fixed technically.
so, testing can you give the impression that the mixture works,
It's not testing that gives the impression that it works; it's the package dependencies. Testing merely relies on the impression they give. If that impression is wrong, then the dependencies are broken, and they should be fixed.
You might need to say something like: Package: kfoo Depends: kdebase (>= 3.3), kde-api-13 Package: kdebase Version: 3.3.1 Provides: kde-api-13 Package: kdebase Version: 3.3.2 Provides: kde-api-13 Package: kdebase Version: 3.3.3 Provides: kde-api-14if KDE 3.3.1 and 3.3.2 are compatible, but 3.3.3 isn't, for example. I've no idea what's actually the case. Probably you'll want to say something more complicated, if kdebase and kdelibs and kdepim become "incompatible" at different times. That's fine, and it's quite possibly not something you can think through in time for sarge. But it's something you (KDE) guys need to think through, not just blame on the testing scripts and ignore.
Cheers, aj
signature.asc
Description: OpenPGP digital signature