Den Friday 20 April 2007 14:42:42 skrev Henne Vogelsang: > > I like the suggestion a lot. The user will specifically want to > > install the packman versions of crippled packages, but won't want > > build service re-cripped newer versions to override them. > > This is is such a special usecase that you will only be able to solve > this, without user knowledge, if you can mark repos as leading, > authorative or whatever. I dont think you can (and should) solve these > usecases on a package level.
I think this is a quite common usecase actually. Many users will have KDE-backports, Packman and Guru and many packages exist on two out of the three repos. And if you're not paying attention you'll be playing 'ping-pong' as so elegantly put by Duncan. Amarok (most people will want Guru, BS version is crippled wrt. database support I believe) Ktorrent (most people will want Guru, BS-version crippled wrt. DHT) Digikam (most people will want the backported version cuz the packman version causes problems with some libs) K3b (sometimes packman has had development builds, which not all will want) Alsa (if your sounds working nicely why would you want to do a risky upgrade automatically for something like that). To name a few very popular packages where I'm aware of problems (presently or in the past). I wonder, do kde-backports and kde-playground have same vendor? If not this behaviour would also make it possible to have kde-playground enabled for certain packages, without constantly having to be alert as to whether you're updating to something alphaish. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
