Re: KMail and Debian packages
On Wed, Nov 21, 2001 at 08:52:09PM +0100, Magnus von Koeller wrote:
> On Wednesday 21 November 2001 19:43, Ivan E. Moore II wrote:
> > HELL NO!
>
> Whew ... First of all, why don't you cool down a little? It's not
> that I want to hurt you or even say that you did something wrong. I
> just want to talk about ways of making this work better.
I'm not upset or irate or anything. Just stressing how much of a no-no that
is.
> > that would mean that if I make a minor fix (say a typo
> > fix in the description or something that is Debian specific but
> > with no code change) that every single app would need to be rebuilt
> > and uploaded.
>
> Okay. I get it. But wouldn't it be possible to, say, let KMail depend
> on only a major KDE release (2.2.1, for example) and not on a single
> Debian sub-release of it (-x)?
we could add dependencies until the cows come home... ie...
depends on >= version x but not version y and less then version z...
but the question is...what good would it do us now? The next version of
KDE is 3 and the package names are different so putting in hacks (which is
all they are) won't do a bit of good.
> > > Actually, right now the problem is that KMail hasn't gotten
> > > through to testing yet but if the current KMail package depended
> > > on kdelibs=2.1.2 and kdebase=2.1.2 then these upgrades would be
> > > held back, too, right?
> >
> > How about this everyone... if you want something stable..use
> > stable and don't use testing.
>
> Well, you know as well as everybody else that potato (stable) is
> quite outdated now. And for a desktop machine that's not really
> mission critical testing is _the_ perfect choice of all distributions
> because you can always be close to the cutting edge while still
> having a considerably stable (which means basically usable) system
> and not having to compile everything yourself.
>
> The real problem here, though, is not that users complain about their
> system being a little unstable but that the developers of KMail are
> being bug-spammed. So there _is_ a problem that deserves fixing
> (IMHO) so maybe we should talk about it.
what I don't understand is that testing breaks majorly quite often...so
you would think that users would get use to this.
> > I am not going to put in hacks to make things work for testing.
> > That's just not the right way to go about things.
>
> I don't really get why this would be such a dirty hack.
>
> P.S.: I'm quite new to Debian so maybe I don't have a clue.
> P.P.S.: I _REALLY_ appreciate your work, especially as a new Debian
> user. This distribution rocks and since I'm using KDE quite a lot you
> are an important part of it.
it's a hack because it only takes care of a specific situation which only
exists for a short period of time and is only a result of the diversity
of the Debian distribution. The only reason kmail (and the rest of the
kdenetwork packages) didn't go into testing when kdelibs did was because
of the mips architecture which is having problems building it right now.
it's a bad hack because putting too many specific deps on packages will cause
things like this:
kdelibs won't go into testing because the packages in testing depend on
a specific version of kdelibs and if kdelibs goes in they will no longer
be installable. Ok..no biggy if and only if every single package that
depends on kdelibs is built on all archs, have been in unstable for 2 weeks,
*AND* do not have any RC bugs against them.
^^^ that is a bitch to have happen espcially since developers have to
constantly fight off RC bugs that are only with packages in testing, work
on getting packages to build on all archs, and have to work at upstream's
pace. Upstream developers have a tendancy not to want to deal with *old*
releases. Getting KDE folks to back port fixes to the 2.2 branch is getting
harder and harder. They are busy working on the next release and like all
of us don't have time to mess with stuff they no longer use.
Now..above and beyond that it also ties my hands as the package of kdelibs...
I cannot make uploads as often as it affects not just a couple packages but
several dozen packages.
all of this just to make sure that testing doesn't have a few weeks where
if a user upgrades they'll have a broken package becuase of mixed libs.
Ivan
--
----------------
Ivan E. Moore II
rkrusty@tdyc.com
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Reply to: