On Wed, Mar 17, 2010 at 03:24:19PM -0300, Felipe Sateler wrote:
On Wed, Mar 17, 2010 at 14:46, Jonas Smedegaard <d...@jones.dk> wrote:

What I propose is to ship the new code as a separate source package and a separate binary package.  The binary package will conflict with the similar binary package provided by the older code (at least at first), and probably no binary library packages will be provided either.

My proposal is to package jackd2 _distributable_ in parallel to existing stable jackd1 but not _installable_ in parallel.

There is a problem, though. The library names collide, so one would
have to have libjack1-0 and libjack2-0. This would mean that the
shlibs files would have to provide alternative dependencies (like
ffmpeg is doing for the unstripped variants), which would require a
binNMU run to change the dependencies, and finally then jack2 could be
uploaded. Oh and take steps to make sure jackd1 depends on libjack1-0
only (and same for jack2). I think this is much too complicated.

Oh, you mean both use unversioned soname?

Yes, that complicates things.

Then how about simply doing the switch now? What are the actual expected risks of using jackd2?

Adrian mentioned FFADO changes and manpage updates. Any other known risks, beyond the general "not well tested"?

  - Jonas

* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

   [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to