Re: jack 0.94.0-2
On Fri, 27 Feb 2004, Free Ekanayaka wrote:
> Robert, as stated in my previous post, I'd like to keep synchronized
> DeMuDi with Debian with respect to the jack library. Is there a time
> line which maintainers of jack dependent packages are supposed to
> respect when a new version of the jack library is uploaded and all
> such packages need to be rebuilt?
Hmm. For 0.94.0-2 nothing has to be rebuild. It contains only small
fixes. Or am I not understanding you correctly?
For the last upload, the timeline was: as fast as possible ;-]
On Fri, 27 Feb 2004, Junichi Uekawa wrote:
> I'd like the conflicts added so that only one version of libjack
> can be installed at the same time.
> And a provides: line so that future version of libjack can
> provides: and conflicts: that virtual package to ensure
> incompatible libjack/jackd combinations aren't installed
> at the same time.
We had a discussion about this but I can't find it anymore.
Guenter and I pointed out, that you can leave applications installed
that do not always use jackd, like hydrogen, pd or others, even during a
libjack transition. They might fail to run in jack mode, though.
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?
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?
Robert.
--
Reply to: