On Fri, 27 Feb 2004, Robert Joerdens wrote: > So if for example hydrogen is removed from testing during a libjack > transition, it can _not_ stay installed anymore and will be removed by apt, > if all libjacks conflict with each other (or depend on a versioned > jackd, what comes out to be the same). > > That would be a regression which can be quite disturbing because users > of testing might wonder, why their packages get deinstalled. Or am I > predicting a wrong behaviour of apt's algorithm here?
Taking into account that theoretically all applications that support jack in a given (reasonabley stable) system will support the same version (ABI-wise), I think we could live with ppl having to update their whole jack - system, not just a part. I consider it more important to not have a conflicting client-server protocol. See it like this: jackd and libjack are a pair that has to go together, its like a shared library split into to halfs, and only the same versions fit. It would even make sense to put them into one package. I see no reason to install libjack and not the corresponding deamon or vice versa. .. and it solves a lot of headaches for users. So I vote for linking them ... > > Even if we accept the regression, to me it seems more reasonable to let > libjack depend on a versioned jackd; might even allow for finer control. > BTW: How would a "Recomends: jackd (= version)" influence apt's > behaviour WRT removing other packages? AFAIK recommends do not influence apt. .. anyhow, I think Junichi can comment on this (to lazy to think right now :) Guenter
