On Mon, Nov 22, 2004 at 03:30:03PM +1000, Anthony Towns wrote:
> Adeodato Simó wrote:
> > 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.
I agree. In this way, the kde packages have allways been broken. We
have been so far reluctant to enforce all of kde being the same version,
since it would seem make testing maigration even harder - Ie. every
kde release would need to be hinted all packages at once, which wouldn't
certainly help the "make kde safe to trickle in" -requirement.
> 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.3
> Provides: kde-api-14
That is the cleanest idea so far. But we would still need to add
something like:
Package: kdebase
Conflicts: kfoo ( << 3.3.0 ), kfoo2 ( << ...
Provides: kde-api-13
Since in sid (and sarge) kde packages do not depend on a kde-api virtual
package. Adding lots of versioned Conflicts was something that was
strongly discouraged by apt maintainers[1] and the policy...
> if 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.
In theory, kde x.y.* should be api/abi compatible. In practice, upstream
may change method in kdelibs between 3.3.2 and 3.3.3 after noticing
that the only user of that method is a plugin in kmail, change the
few place the method is used, and and assume that nobody is going to
notice.
The most conservetive assumptation would be to assume that only
packages of version x.y.z will work together, since that is the only
thing upstream tests and guarantees to work.
> 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.
We probably can do the "think" part in time, enforcing stricter
relationships for kde packages has been under thinking for a while
(atleast since the kde 3.2 migration to sarge). We are certainly not
ignoring the issue, so far effort has been focused in making
kde 3.3 RC-clear with as little as possible structural changes
to avoid breaking things this close the release.
If you and the Release maintainers believe, that this in issue that
must be solved for kde3.3 to enter sarge (despite the fact that
kde 3.2 is sarge suffers from the same problem), we sould
probably need to reupload most kde packages, which on the other hand
will not make it in the time for sarge :-/ Which is kinda demotivating,
since almost every kde package is valid candinate at the moment..
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183702&msg=27
