On Wed, Apr 21, 2010 at 13:30:55 (CEST), Jonas Smedegaard wrote:
>>>> I don't understand the libjack-0.116.0 thing. Is that going to be
>>>> the package name? If so, that sounds like we would be repeating the
>>>> libjack0.100.0 mistake.
>>>
>>> It is more like an add-on tag, indicating the library ABI.
>>
>> I deduce from this that you don't want to adjust the shlibs file of
>> libjack package to make application package generate dependencies on
>> libjack-0.116.0 then?
>
> No, I want to adjust shlibs file later on, but not required for step 1.
I don't see a reason to delay this. Details follow.
>> So to put straight: you propose to not switch to jackd2 at all but
>> stick with jackd1? I guess you are aware that adi has negotiated with
>> opensuse to do a coordinated switch to jackd2, and is currently trying
>> to agree on something similar with fedora? I think that stepping back
>> from this plan would makes us look, well, strange.
>
> I want to switch, but a) without lock-in on jackd2 (since that has
> turned out to not be the only potential future) and b) without
> geopardizing the release process.
>
> Generally speaking (please let us discuss technical details in a
> separate subthread - I will fork one when done writing this), I see 3
> possible ways forward:
>
> * conservative: Stay with jackd1, ignoring jackd2 and tchack.
> * stubborn: Switch to jackd2, abandoning jackd1 and ignoring tchack.
> * bold: switch to supporting multiple implementations.
>
> You seem to want the stubborn path, because a cross-distro wave have set
> off.
I think adi should decide on this. And AFAIUI, adi has already decided
to go with jackd2. He visited me a few weeks ago at my workplace here
(he happened to be around for a workshop at my university) and we
discussed the pro and cons for the various jack implementations. His
arguments were pretty convincing that jackd2 was the best implementation
for squeeze.
NB: I don't use jack myself, so I don't consider myself qualified to
actually backup such a decision. I just point out the results of the
previous discussions on this topic.
> I wanted to push jackd2 back when it was seen as the only future, only a
> question on when to make the switch. But when it turns out jackd1 is
> intended to be kept alive or and tchack exist as a third possible
> future, I find it wrong to pick a single future immaturely.
The future in the short term seems to including competing yet binary
compatible implementations of jack. We as a distribution can (and I
think also should) fulfill the following goals:
- decide on a default implementation
- allow users to switch and use a non-default implementation
When torben mailed our mailing list, I didn't have the impression that
he advocated jack1 to be the default; au contraire, I think he even
supported the decision to go with jackd2 (but I may be wrong here). He
merrily asked to consider the 2nd point, so that he is in a position to
provide drop-in 3rd party packages on the jack1 website that don't
require to have all applications rebuilt.
> So I want to keep jackd1 alive and _then_ include jackd2, not include
> jackd2 as replacement for jackd1. Which means there is a _risk_ that
> jackd2 will not reach inclusion into Squeeze.
>
>
> In other words, I propose a 4th path:
>
> * cautious: first conservative, then gradually bolder.
I think we have to face two different changes:
a) switch the default implementation
b) restructure the packaging so that users can switch from one
implementation to another one.
I don't see the reason to wait with a) (adi discussed this months! ago
on this mailing list), and for b), I have technical concerns. But let's
discuss them in the other thread.
> Others looking strangely at Debian is nothing new: When I started using
> Debian in the last millenium, Redhat and SuSE users emphasized the
> weirdness of Debian not using upstream library naming but renaming to
> make it possible to handle multiple ABIs (or whatever it is called, not
> important here) in the distribution - either concurrently installable or
> conflicting but at least available in same release of the distro.
Which is a good example why we should continue to make technical sound
decisions, but has nothing to do with the fact that adi is now in a very
difficult position with his correspondence with other distros.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
