Re: packaging jack - details on plan B

2010-04-26 Thread Reinhard Tartler
On Mon, Apr 26, 2010 at 04:38:17 (CEST), Felipe Sateler wrote:

 On Sun, Apr 25, 2010 at 14:27, Reinhard Tartler siret...@tauware.de wrote:
 On Sun, Apr 25, 2010 at 19:47:47 (CEST), Jonas Smedegaard wrote:

 I notice, though, that above links only mention API, not ABI.  Is it
 safe to expect library ABI (runtime linkage) to be frozen too if its API
 (compile time interface) is?

 Generally speaking, yes.

 (well, unless there are toolchain changes, etc. - very unlikely at this
 stage of squeeze)

 Not really. Reordering of enums, for example, could break ABI while
 keeping API compatibility. Same with adding/reordering struct members.
 Not relally common, but can happen.

Oh, you're totally right. Somehow I considered these changes as API
change as well, but what is meant here is a change that does not affect
buildability.

Other API compatible changes in C++ would e.g. include addition of
additional parameters to existing methods with default parameters. This
would affect ABI as well.

I was clearly confused yesterday, sorry.

-- 
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


Re: packaging jack - details on plan B

2010-04-26 Thread Gabriel M. Beddingfield



On Sun, 25 Apr 2010, Jonas Smedegaard wrote:

I notice, though, that above links only mention API, not ABI.  Is it safe to 
expect library ABI (runtime linkage) to be frozen too if its API (compile 
time interface) is?


Answer from upstream:

Date: Mon, 26 Apr 2010 09:34:26 -0400
From: Paul Davis p...@linuxaudiosystems.com
To: Gabriel M. Beddingfield gabrb...@gmail.com
Cc: Jack-Devel jack-de...@lists.jackaudio.org
Subject: Re: [Jack-Devel] packaging jack - details on plan B (fwd)

On Mon, Apr 26, 2010 at 9:20 AM, Gabriel M. Beddingfield gabrb...@gmail.com 
wrote:

Jack Devs:


Please see the below e-mail (from debian packaging list) where Jonas would
like a clarification about Jack's ABI compatability.  I'm sure the answer is
yes... but I wanted to check with you guys one more time.



he asked I notice, though, that above links only mention API, not ABI.  Is
it safe to expect library ABI (runtime linkage) to be frozen too if its API
(compile time interface) is?

I think that the answer is yes. Certainly I am not aware of any cses where
switching from one version of JACK to another has caused ABI issues. We've
never had it as a hard, explicit rule that development would follow this
rule, but its always been an implicit goal and is a fairly natural
consequence of the development pattern for JACK.

again, this clearly only applies in the upward case - ABI
back-compatibility has never been assured - if a program was linked against
JACK API M.N.m and the runtime installation is a version earlier than that,
there may be problems as you noted. the new rules on weak symbols post the
0.118.0 API should help address this.

--p


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-26 Thread Jonas Smedegaard

On Mon, Apr 26, 2010 at 08:29:40AM -0500, Gabriel M. Beddingfield wrote:

On Sun, 25 Apr 2010, Jonas Smedegaard wrote:

I notice, though, that above links only mention API, not ABI.  Is it 
safe to expect library ABI (runtime linkage) to be frozen too if its 
API (compile time interface) is?


I'm sure that the answer is yes, but I've asked the upstream devs to 
confirm it.


Cool!


 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-26 Thread Jonas Smedegaard
On Mon, Apr 26, 2010 at 9:20 AM, Gabriel M. Beddingfield 
gabrb...@gmail.com wrote:


ABI back-compatibility has never been assured - if a program was 
linked against JACK API M.N.m and the runtime installation is a 
version earlier than that, there may be problems as you noted. the 
new rules on weak symbols post the 0.118.0 API should help address 
this.


Do I understand above correctly so that in fact jackd2 1.9.5 cannot be 
trusted to support library API (and ABI) of 0.116.2 but only that of 
0.118.0?


Tell me if better that I ask upstream such questions.  For now I would 
prefer this list acting as proxy for my perhaps too silly[1] questions.



 - Jonas

[1] No question is too silly to be asked, I know.  But some might be 
silly enough that others than busy upstream developers can answer. :-)


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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-26 Thread Gabriel M. Beddingfield



On Mon, 26 Apr 2010, Jonas Smedegaard wrote:

On Mon, Apr 26, 2010 at 9:20 AM, Gabriel M. Beddingfield 
gabrb...@gmail.com wrote:


ABI back-compatibility has never been assured - if a program was linked 
against JACK API M.N.m and the runtime installation is a version earlier 
than that, there may be problems as you noted. the new rules on weak 
symbols post the 0.118.0 API should help address this.


Do I understand above correctly so that in fact jackd2 1.9.5 cannot be 
trusted to support library API (and ABI) of 0.116.2 but only that of 0.118.0?


Correct.

If you compiled against the libs from 0.100.0, 0.109.0, 
0.116.2, 0.118.0, etc. it will work fine with 1.9.5.


If you compiled against the libs from 1.9.5, it will work 
fine with = 0.118.0.


-gabriel


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-25 Thread Jonas Smedegaard

On Fri, Apr 23, 2010 at 03:36:02PM -0500, Gabriel M. Beddingfield wrote:


Hi Jonas,

On Fri, 23 Apr 2010, Jonas Smedegaard wrote:


[3] Going backwards has never been promised, though.  A
  program compiled against 0.118.0 will work with 0.34.0.
  However, the use of weak symbols for new features may
  make this available.


Isn't it exactly going backwards if jackd2 becomes the default 
and jackd1 only an optional alternative?  Then applications are 
compiled against jackd2 and potentially using jackd1 at runtime.  
Is that assured to work too, or only hopefully working if weak 
symbols work out as planned?


Jack2/Jack1 are API-synchronized.  Here are the sync points that have 
been published:


   JACK1JACK2 REF
   ---  -  
   0.118.0  1.9.4  [1]
   0.116.2  1.9.1  [2], [3]

It is reasonable to expect that a program compiled against Jack2 
1.9.1 will work fine with 0.116.2.


Note also that the API changes since 0.109.0 (the first stable JACK 
MIDI release) have been minor.  (Adding weak symbols, internal 
changes, documentations, internal header reorg.)


HTH,
Gabriel

[1] http://jackaudio.org/node/28
[2] http://jackaudio.org/node/23
[3] http://jackaudio.org/node/22



Thanks for the clarification.

I notice, though, that above links only mention API, not ABI.  Is it 
safe to expect library ABI (runtime linkage) to be frozen too if its API 
(compile time interface) is?



Kind regards,

 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-25 Thread Reinhard Tartler
On Sun, Apr 25, 2010 at 19:47:47 (CEST), Jonas Smedegaard wrote:

 I notice, though, that above links only mention API, not ABI.  Is it
 safe to expect library ABI (runtime linkage) to be frozen too if its API
 (compile time interface) is?

Generally speaking, yes.

(well, unless there are toolchain changes, etc. - very unlikely at this
stage of squeeze)

-- 
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


Re: packaging jack - cross-distro coordination

2010-04-24 Thread Jonas Smedegaard

On Sat, Apr 24, 2010 at 02:39:16AM +0200, Adrian Knoth wrote:


We instantly switch to jackd2. End of the story.


Thanks for a clear cut message.

I can accept that.

If noone else has a say against it within the next 24h (where I am busy 
anyway attending some family business) I will release jackd2 as a 
replacement for jackd1 (i.e. using same source and binary package 
names).



 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - cross-distro coordination

2010-04-24 Thread Reinhard Tartler
On Sat, Apr 24, 2010 at 09:00:17 (CEST), Jonas Smedegaard wrote:

 On Sat, Apr 24, 2010 at 02:39:16AM +0200, Adrian Knoth wrote:

We instantly switch to jackd2. End of the story.

 Thanks for a clear cut message.

 I can accept that.

 If noone else has a say against it within the next 24h (where I am busy
 anyway attending some family business) I will release jackd2 as a
 replacement for jackd1 (i.e. using same source and binary package
 names).

I support this approach.

This leaves us time to sort out the details of the restructuring of the
packages while jackd2 finds its way to testing.

-- 
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


Re: packaging jack - cross-distro coordination

2010-04-24 Thread Free Ekanayaka
Hi,

|--== On Sat, 24 Apr 2010 09:11:27 +0200, Reinhard Tartler 
siret...@tauware.de said:

  RT On Sat, Apr 24, 2010 at 09:00:17 (CEST), Jonas Smedegaard wrote:
  On Sat, Apr 24, 2010 at 02:39:16AM +0200, Adrian Knoth wrote:
  
  We instantly switch to jackd2. End of the story.
  
  Thanks for a clear cut message.
  
  I can accept that.
  
  If noone else has a say against it within the next 24h (where I am busy
  anyway attending some family business) I will release jackd2 as a
  replacement for jackd1 (i.e. using same source and binary package
  names).

  RT I support this approach.

I'm all for it as well, it looks like the most reasonable move to me,
glad to see things will move forward.

Ciao!

Free

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - cross-distro coordination

2010-04-24 Thread Gabriel M. Beddingfield



On Sat, 24 Apr 2010, Jonas Smedegaard wrote:


On Sat, Apr 24, 2010 at 02:39:16AM +0200, Adrian Knoth wrote:


We instantly switch to jackd2. End of the story.


Thanks for a clear cut message.

I can accept that.


For Squeeze, I'm OK with this, too.

-gabriel

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - cross-distro coordination

2010-04-24 Thread Reinhard Tartler
On Fri, Apr 23, 2010 at 22:11:15 (CEST), Jonas Smedegaard wrote:

 Regarding options:

 Let me try summarize anew, given my new understanding (dropping
 potentially provocative names):

   a) Stay with jackd1, ignoring jackd2 and tchack.
   b) Switch to jackd2, abandoning jackd1 and ignoring tchack.
   c) switch to supporting multiple implementations.

Is, I think these are our options at this point.

 Let me try summarize anew, given my new understanding (dropping
 potentially provocative names):

   a) Release Squeeze only with jackd1
   b) Release Squeeze only with jackd2, replacing jackd1
   c) Release Squeeze with jackd1 as default, and optionally jackd2
   d) Release Squeeze with jackd2 as default, and optionally jackd1

 I agree that adi already decided on b).  But at a time when jackd1
 seemed dying and jackd2 its natural replacement - just a question of
 when to switch.  Options like c) and d) was only considered as a more
 gentle transition method, which was later deemed unnecessary.

 In other words, it is not my impression that adi already decided on d).

If you put it this way, indeed. the options c) and d) came up after
torben asked us support multiple implementations.

 I do not want jackd1 as default due to being best, but due to being most
 tested.  We are close to release, so any radical is risky.

AFAIUI jackd2 is tested well enough, generally speaking, you are of
course right.

 Switching from jackd1 to jackd2 as default (or only) library and daemon
 is a radical change, which we agreed to do anyway.

 Implementing support for multiple implementations of the JACK interfaces
 is yet another radical change.

 Two radical changes is one too many IMHO.

Well, given the circumstances, I would still consider this option.

 Replacing jackd1 because we consider it obsolete seemed a valid argument
 for me to take the risk.  But doing it not because we consider it
 obsolete but because we consider it still valid just less interesting is
 too weak argument for a too big risk this late in the game IMO.

sure, you're call. It seems I have a different opinion about the risks
of our options, though.

 You (or adi?) want this:

   1) replace jackd1 with jackd2
   2) readd jackd1 differently named as optional alternative

 Both of those are risky: The first might reveal problems when
 recompiling against claimed compatible but potentially not in reality
 compatible library API and daemon runtime ABI. 

Well, upstream claims that this has been tested in depth. I'm inclined
to trust upstream here.

 The second might cause problems in designing package interrelations
 correctly, and (depending on degree of offered replacements) linking
 and compiling issues as well.

indeed.

 I want this instead:

   1) keep jackd1 as is at first
   2) add jackd2 as optional alternative
   3) switch around to have jackd2 as default

 At each step we may run out of time and ship that with Squeeze.  It
 makes better sense for me to risk shipping only something too boring for
 professionals to use but not broken, rather than something maybe broken
 and not discovered as such in time because we were busy complicating
 things even furthere.

I see.

 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.

 I do not expect us to reach to goal of properly handling multiple
 competing JACK implementations in time for the freeze of Squeeze!

Well, okay, but missing this would be a real shame :-(

-- 
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


Re: packaging jack - cross-distro coordination

2010-04-24 Thread Eric Dantan Rzewnicki
On Sat, Apr 24, 2010 at 06:38:09AM -0500, Gabriel M. Beddingfield wrote:
 On Sat, 24 Apr 2010, Jonas Smedegaard wrote:
 On Sat, Apr 24, 2010 at 02:39:16AM +0200, Adrian Knoth wrote:
 We instantly switch to jackd2. End of the story.
 Thanks for a clear cut message.
 I can accept that.
 For Squeeze, I'm OK with this, too.

I see a consensus. Yay! :)

-edrz

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-23 Thread Jonas Smedegaard

Hi Reinhard and others,

On Wed, Apr 21, 2010 at 02:16:36PM +0200, Jonas Smedegaard wrote:

On Wed, Apr 21, 2010 at 12:26:41PM +0200, Reinhard Tartler wrote:


With you're proposal, I think switching from one alternative 
implementation to another one won't work. For example switching 
from tschack to jackd3 would break with undeclared file conflicts 
AFAIUI. And my understanding of this whole hickhack was to allow 
users to switch jack implementations without having to recompile 
packages.


If I understand your concern correctly, it is easily handled using 
Replaces:.


I deliberately did not go into such details, as I can easily imagine 
lots of details being forgotten, but cannot imagine it eventually 
done right.


In other words: Do you only fear that I forgot some details, or do 
you fear that it is impossible to implement at all like I drafted, 
even with carefully composed package relations?


Ping!



(If it works) my idea would allow this; and without having each and 
every implementation to declare conflicts against every existing 
other implementation.


Sorry, I lost track: Could you please, in a differently named 
subthread, repeat your proposal?


Ping!


If I get no response on this by sunday, and noone else objects, I will 
go ahead with my proposed plan.


Please do respond - I realy do want input on this, and may very well 
have missed something obvious to oters that make the plan not work out 
at all.


Also, please do speak up if anyone feels they made earlier proposals 
still valid to compare against.  I sincerely apologize if missing out on 
them - I lost track of it in these discussions, and did not find/take 
the time to go through the whole thread to isolate them.



Kind regards,

 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-23 Thread Eric Dantan Rzewnicki
On Fri, Apr 23, 2010 at 10:55:20AM +0200, Jonas Smedegaard wrote:
 Hi Reinhard and others,
 On Wed, Apr 21, 2010 at 02:16:36PM +0200, Jonas Smedegaard wrote:
 On Wed, Apr 21, 2010 at 12:26:41PM +0200, Reinhard Tartler wrote:
 With you're proposal, I think switching from one alternative  
 implementation to another one won't work. For example switching from 
 tschack to jackd3 would break with undeclared file conflicts AFAIUI. 
 And my understanding of this whole hickhack was to allow users to 
 switch jack implementations without having to recompile packages.
 If I understand your concern correctly, it is easily handled using  
 Replaces:.
 I deliberately did not go into such details, as I can easily imagine  
 lots of details being forgotten, but cannot imagine it eventually done 
 right.

 In other words: Do you only fear that I forgot some details, or do you 
 fear that it is impossible to implement at all like I drafted, even 
 with carefully composed package relations?
 Ping!

 (If it works) my idea would allow this; and without having each and  
 every implementation to declare conflicts against every existing  
 other implementation.
 Sorry, I lost track: Could you please, in a differently named  
 subthread, repeat your proposal?
 Ping!

 If I get no response on this by sunday, and noone else objects, I will  
 go ahead with my proposed plan.

 Please do respond - I realy do want input on this, and may very well  
 have missed something obvious to oters that make the plan not work out  
 at all.

 Also, please do speak up if anyone feels they made earlier proposals  
 still valid to compare against.  I sincerely apologize if missing out on  
 them - I lost track of it in these discussions, and did not find/take  
 the time to go through the whole thread to isolate them.

I've tried to follow this as closely as I can, but I am new to packaging
so not qualified to discuss the specifics.

However, from what I do understand I do not see a consensus, yet. Also,
I would ask that we restate and clarify the proposed scheme and give
upstream a chance to comment.

NB: though torben is truly awesome, he is not the only upstream
developer.

-edrz

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-23 Thread Reinhard Tartler
On Wed, Apr 21, 2010 at 14:16:36 (CEST), Jonas Smedegaard wrote:

  2. Initially release src:jackd2:
 * jackd2 conflicts/replaces/provides jackd
 * libjack0-jackd2 conflicts/replaces libjack0
 * libjack0-jackd2 provides libjack-0.116.0
 * libjack-jackd2-dev conflicts libjack-dev
 * Big fat warning to use -dev package only privately

So you propose to introduce 2 virtual packages: jackd and
libjack-0.116.0? What problem does introducing the virtual package jackd
solve?

ping?


  3. Initially release src:tchack, like jackd2
  4. Update jack-depending packages after testing that it works:
 * Add libjack-0.116.0 as fallback-dependency for libjack0

Ah, so at this point you propose to introduce a shlibs file like:

,[proposed shlibs file]
| libjack0 0 libjack0 (= 0.116) | libjack-0.116.0
`

is that correct?

 Yes, correct.

 But an important detail is that I do *not* introduce that virtual
 package to the currently stable jackd1 packaging, only to newly
 introuced jackd2 and tchack packagings!

 Only when proven reliable do I want to infect the stable package or
 other jack-dependent packages!

As indicated in the other mail, we have two objectives:

 a) switch the default implementation
 b) rearrange packaging to support switching the used implementation

I think b) can and should be done independently on the choice of a),
which means any change to packaging needs to work even if stick with
jack1. Therefore, there is no reason to loose time with planning and
starting the upcoming jackd transition.

 The reason for this is the logic of molding a new Debian releaase: It is
 much easier to rip out newly introduced oddities with not depended on by
 other already-accepted packages, than it is to fix problems involving
 chains of package rebuilds.

You seem to insist on deciding a) before b), while I'd rather see b)
implemented before a), because a) [switching the default implementation]
is technically much easier to implement than b) [packaging changes],
which requires rebuilds of existing packages and therefore takes
potentially a lot of time (build time, coordination with the release
team, etc).

 This also means we do not need to set it all in stone: we do not need to
 discuss *now* what exact wording of each shlib file or naming of virtual
 packages - only if suspected to not work at all is it relevant to
 discuss *now*, else we move faster if discussing and implementing in
 parallel.

I think this is essential for implementing and reviewing the
implementation of step b).

 (I do feel that you suspect the grand plan to not work at all, so do not
 want to stop the current discussion, just want to warn about it
 exploding into all sorts of details not needed to discuss ahead)

You're right, I fear step b) will be technically challenging and I offer
my experience from a similar trick in the FFmpeg packages to review its
implementation.

How is the libjack0 package from other implementations supposed to look
like? Something like this?

Package:   libjack-jackd2-0
Provides:  libjack-0.116.0
Conflicts: libjack0

 Yes, something like that.


  4. Release jackd1 to experimental, with libjack0 providing   virtual
 package libjack-0.116.0
  5. Repackage jackd1 to experimental, with libjack0 providing   virtual
 package libjack0-0.116.0

what actual changes are involved in this repackaging?

 This step is not needed for technical reasons but was included for
 potential political reason: not in the long term emphasize jackd1 as
 being better than the other implementations.

Then let's make all applications to depend on 'libjack0-0.116.0', which
refers to the ABI, and provide a package 'jack-defaults', which builds a
meta-package 'jackd' which depends on the distribution chosen 'default'
jack implementation.

This is similar to the 'gcc-defaults' and 'python-defaults' packages.


 If it truly is irrelevant if a jack-dependent package build against
 jackd1, jackd2 or tchack, then it might (or might not!) make sense to
 stop promoting jackd1 as the most rightous of the implementations.

It depends on the package. Of course there are packages that only work
with a specific libjack implementation. The most prominent example for
this are the respective jack daemon packages. These packages do need a
shlibs.local to override our default libjack shlibs file. This can and
probably will also affect some other jack application packages.

 We could either just abandon the libjack0 and libjack-dev as real
 packages and only rely on virtual package names for build-dependencies
 of common-ABI-conforming projects.

Which is more or less what I propose.

 Or we can create a set of empty meta-packages e.g. libjack-abi-0.116.0
 and libjack-abi-0.116.0-dev, depending on the implementations truly
 obeying the declared ABI - making it possible to ease transition to
 newer ABI if API does not change, even if not all implementations do
 not switch to that newer API at the exact same time (or maybe some of
 them 

Re: packaging jack - details on plan B

2010-04-23 Thread Jonas Smedegaard

On Fri, Apr 23, 2010 at 07:35:28AM -0400, Eric Dantan Rzewnicki wrote:

On Fri, Apr 23, 2010 at 10:55:20AM +0200, Jonas Smedegaard wrote:


If I get no response on this by sunday, and noone else objects, I 
will go ahead with my proposed plan.


I've tried to follow this as closely as I can, but I am new to 
packaging so not qualified to discuss the specifics.


However, from what I do understand I do not see a consensus, yet. Also, 
I would ask that we restate and clarify the proposed scheme and give 
upstream a chance to comment.


NB: though torben is truly awesome, he is not the only upstream 
developer.


Thanks for the response.  I shall not touch the libjack packaging (even 
step one that I find glaring and obvious) until others have explicitly 
requested so and not been disputed by others on this list.



 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-23 Thread Gabriel M. Beddingfield


Hi guys,

I'm new to the details of deb packaging... so I may be 
replying to the wrong snippets... but:



Package:   libjack-jackd2-0
Provides:  libjack-0.116.0
Conflicts: libjack0


Yes, something like that.



 4. Release jackd1 to experimental, with libjack0 providing   virtual
package libjack-0.116.0
 5. Repackage jackd1 to experimental, with libjack0 providing   virtual
package libjack0-0.116.0


what actual changes are involved in this repackaging?


This step is not needed for technical reasons but was included for
potential political reason: not in the long term emphasize jackd1 as
being better than the other implementations.


Then let's make all applications to depend on 'libjack0-0.116.0', which
refers to the ABI, and provide a package 'jack-defaults', which builds a
meta-package 'jackd' which depends on the distribution chosen 'default'
jack implementation.


I don't understand why we're emphasizing the ABI of 
`libjack0-0.116.0'.


According to the Jack devs, a program compiled against Jack 
0.34.0 (released ca. 2001) is still binary-compatible with 
/any/ Jack implementation (whether Jack1, Jack2, tschack, 
etc.)  They have rigorously been maintaining this. 
Therefore, any old program will work without recompile on a 
new libjack0.  Jack 2 (formerly jackdmp) has also rigorously 
maintained binary compatability with Jack 1.[3]


Therefore, the virtual package should be `libjack0', not 
`libjack0-0.116.0'.  See also [1] and [2].


Also, I'm sure you're on top of it, but it's important that 
this:


$ gcc -o foo `pkg-config --cflags --libs jack` foo.cpp

...does the right thing with:

$ dpkg-shlibdeps foo

Thanks,
Gabriel

[1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach
[2] http://subversion.jackaudio.org/jack/tags/RELEASE_0_118_0/README.developers
[3] Going backwards has never been promised, though.  A
program compiled against 0.118.0 will work with 0.34.0.
However, the use of weak symbols for new features may
make this available.



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - cross-distro coordination

2010-04-23 Thread Jonas Smedegaard

On Fri, Apr 23, 2010 at 01:48:01PM +0200, Reinhard Tartler wrote:

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.


Understood (although I do not agree).  Sorry for too simplified summary 
of options - that was not intentional.




Generally speaking [...], 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.


Regarding earlier decision:

I believe previous discussions could be summarized as this list of 
choices:


  a) Release Squeeze only with jackd1
  b) Release Squeeze only with jackd2, replacing jackd1

I got the impression that even if an option of shipping with both was 
discussed briefly, it died due to a general assumption that jackd2 was 
the natural successor of jackd1 and thus keeping both around would only 
be for the sake of slower transistion (i.e. irrelevant if a faster 
switch was deemed realistic).




Regarding options:

Let me try summarize anew, given my new understanding (dropping 
potentially provocative names):


  a) Stay with jackd1, ignoring jackd2 and tchack.
  b) Switch to jackd2, abandoning jackd1 and ignoring tchack.
  c) switch to supporting multiple implementations.




Let me try summarize anew, given my new understanding (dropping 
potentially provocative names):


  a) Release Squeeze only with jackd1
  b) Release Squeeze only with jackd2, replacing jackd1
  c) Release Squeeze with jackd1 as default, and optionally jackd2
  d) Release Squeeze with jackd2 as default, and optionally jackd1

I agree that adi already decided on b).  But at a time when jackd1 
seemed dying and jackd2 its natural replacement - just a question of 
when to switch.  Options like c) and d) was only considered as a more 
gentle transition method, which was later deemed unnecessary.


In other words, it is not my impression that adi already decided on d).

I do not want jackd1 as default due to being best, but due to being most 
tested.  We are close to release, so any radical is risky.


Switching from jackd1 to jackd2 as default (or only) library and daemon 
is a radical change, which we agreed to do anyway.


Implementing support for multiple implementations of the JACK interfaces 
is yet another radical change.


Two radical changes is one too many IMHO.


Replacing jackd1 because we consider it obsolete seemed a valid argument 
for me to take the risk.  But doing it not because we consider it 
obsolete but because we consider it still valid just less interesting is 
too weak argument for a too big risk this late in the game IMO.






I sincerely want jackd2 as default in a multi-implementation scenario.  
I just feel that we are too close to release to make multiple risky 
steps.


You (or adi?) want this:

  1) replace jackd1 with jackd2
  2) readd jackd1 differently named as optional alternative

Both of those are risky: The first might reveal problems when 
recompiling against claimed compatible but potentially not in reality 
compatible library API and daemon runtime ABI.  The second might cause 
problems in designing package interrelations correctly, and (depending 
on degree of offered replacements) linking and compiling issues as well.


I want this instead:

  1) keep jackd1 as is at first
  2) add jackd2 as optional alternative
  3) switch around to have jackd2 as default

At each step we may run out of time and ship that with Squeeze.  It 
makes better sense for me to risk shipping only something too boring for 
professionals to use but not broken, rather than something maybe broken 
and not discovered as such in time because we were busy complicating 
things even furthere.



I wanted to push jackd2 back when it was seen as the only future, 
only a question on when to make 

Re: packaging jack - details on plan B

2010-04-23 Thread Jonas Smedegaard

On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote:

Therefore, any old program will work without recompile on a new 
libjack0.  Jack 2 (formerly jackdmp) has also rigorously maintained 
binary compatability with Jack 1.[3]


[...]


[3] Going backwards has never been promised, though.  A
   program compiled against 0.118.0 will work with 0.34.0.
   However, the use of weak symbols for new features may
   make this available.


Isn't it exactly going backwards if jackd2 becomes the default and 
jackd1 only an optional alternative?  Then applications are compiled 
against jackd2 and potentially using jackd1 at runtime.  Is that assured 
to work too, or only hopefully working if weak symbols work out as 
planned?



Kind regards,

 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-23 Thread Gabriel M. Beddingfield


Hi Jonas,

On Fri, 23 Apr 2010, Jonas Smedegaard wrote:


[3] Going backwards has never been promised, though.  A
   program compiled against 0.118.0 will work with 0.34.0.
   However, the use of weak symbols for new features may
   make this available.


Isn't it exactly going backwards if jackd2 becomes the default and jackd1 
only an optional alternative?  Then applications are compiled against jackd2 
and potentially using jackd1 at runtime.  Is that assured to work too, or 
only hopefully working if weak symbols work out as planned?


Jack2/Jack1 are API-synchronized.  Here are the sync points 
that have been published:


JACK1JACK2 REF
---  -  
0.118.0  1.9.4  [1]
0.116.2  1.9.1  [2], [3]

It is reasonable to expect that a program compiled against 
Jack2 1.9.1 will work fine with 0.116.2.


Note also that the API changes since 0.109.0 (the first 
stable JACK MIDI release) have been minor.  (Adding weak 
symbols, internal changes, documentations, internal header 
reorg.)


HTH,
Gabriel

[1] http://jackaudio.org/node/28
[2] http://jackaudio.org/node/23
[3] http://jackaudio.org/node/22

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-23 Thread Jonas Smedegaard

On Fri, Apr 23, 2010 at 02:29:00PM +0200, Reinhard Tartler wrote:

On Wed, Apr 21, 2010 at 14:16:36 (CEST), Jonas Smedegaard wrote:



 2. Initially release src:jackd2:
* jackd2 conflicts/replaces/provides jackd
* libjack0-jackd2 conflicts/replaces libjack0
* libjack0-jackd2 provides libjack-0.116.0
* libjack-jackd2-dev conflicts libjack-dev
* Big fat warning to use -dev package only privately


So you propose to introduce 2 virtual packages: jackd and
libjack-0.116.0? What problem does introducing the virtual package jackd
solve?


ping?


Sorry, not sure I understand the question.

Without virtually providing jackd, the jackd2 package does not, well, 
provide jackd.


It will work for packages just wanting _any_ jackd.  Packages like
Ardour that are picky about the version of jackd will need to 
explicitly

state which version of the alternative implementation (if at all) is
acceptable.

Did that answer your question?




As indicated in the other mail, we have two objectives:

a) switch the default implementation
b) rearrange packaging to support switching the used implementation


[...]

You seem to insist on deciding a) before b), while I'd rather see b) 
implemented before a),


No, I explicitly as step 1 *postpone* switching.

Long term I want jackd2 as default.  I just do not want to switch before 
supportive mechanisms for multiple concurrent implementations are 
properly in place.


Seems we actually agree, just talk past each other here :-)


(I do feel that you suspect the grand plan to not work at all, so do 
not want to stop the current discussion, just want to warn about it 
exploding into all sorts of details not needed to discuss ahead)


You're right, I fear step b) will be technically challenging and I 
offer my experience from a similar trick in the FFmpeg packages to 
review its implementation.


It seems you miss my point (contained in the paragraph above which you 
snipped, if I recall correctly):


If you feel that the plan is utterly broken, cannot work, will meet a 
dead end mid way, is impossible(!) to implement, then let us discuss 
fully and in detail untill either agreeing to drop the plan or agreeing 
that it seems doable.


If, on the other hand, you feel that the plan will be technically 
challenging but otherwise is sane, then I strongly suggest to not 
discuss in details all steps of it, but instead discuss when (or if) 
problems are spotted while implementing.





We could either just abandon the libjack0 and libjack-dev as real 
packages and only rely on virtual package names for 
build-dependencies of common-ABI-conforming projects.


Which is more or less what I propose.


So my proposal does not conflict with yours, but optionally includes it.  
Great. :-)



Most likely this step is long after Squeeze.  And quite probably we 
won't do this step at all. Even if completely broken, I do not see 
failure of this step to affect any of the other steps. Is it relevant 
to discuss it in detail now?


Yes, because I think we really can and should implement this for 
squeeze!


You believe we can work fast, and therefore you want us to discuss more 
before we start working?  Even if we do not disagree on the steps, only 
on details within some of the (later) steps?




Do you only fear that I forgot some details, or do you fear that it 
is impossible to implement at all like I drafted, even with carefully 
composed package relations?


I fear that your proposal would require all jack implementation 
packages to be aware of all other competing implementation packages.


I fail to imagine how my *plan* could cause such situation.  It very 
much sounds like ugly _implementaiont_ of that plan.  And something that 
can easily be fixed by adjusting minor packaging hints - not something 
broken in the overall plan, and thus not something relevant to stall the 
work for discussing ahead IMHO.










So yes, I'm more and more convinced that this should work.


this being your proposal or mine?  Or did I (again) misunderstand?


Kind regards,

 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-23 Thread Eric Dantan Rzewnicki
On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote:
 Hi guys,
 I'm new to the details of deb packaging... so I may be replying to the 
 wrong snippets... but:
 [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach

Note that this is a wiki and the suggestions come from only one person.

-edrz

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-23 Thread Gabriel M. Beddingfield


On Fri, 23 Apr 2010, Eric Dantan Rzewnicki wrote:


On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote:

[1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach


Note that this is a wiki and the suggestions come from only one person.


True, but Nedko (the author of the article) shouldn't be 
ignored.  He is very knowledgeable and respected in the 
LAD/Jack communities.


Furthermore, he is saying the exact same thing that Torben 
and I have been saying.


Thanks,
Gabriel

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - details on plan B

2010-04-23 Thread Adrian Knoth
On Fri, Apr 23, 2010 at 05:52:35PM -0500, Gabriel M. Beddingfield wrote:

 On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote:
 [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach

 Note that this is a wiki and the suggestions come from only one person.

 True, but Nedko (the author of the article) shouldn't be ignored.  He is 
 very knowledgeable and respected in the LAD/Jack communities.

 Furthermore, he is saying the exact same thing that Torben and I have 
 been saying.

I mostly agree with the suggested packaging except jackd, jackdbus
and jack server library being separate packages.

Not that it'd be wrong, but the amount of packages seems unnecessarily
high. There are even people who suggest to put everything in a single
jackd1/jackd2 package, but we probably don't want to go this far.


-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack - cross-distro coordination

2010-04-23 Thread Adrian Knoth
On Fri, Apr 23, 2010 at 01:48:01PM +0200, Reinhard Tartler wrote:

   * 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. 

Sorry for kicking in late, I'm horribly busy at the moment. Will
hopefully change after 2010-04-28 (project deadline).

 His arguments were pretty convincing that jackd2 was the best
 implementation for squeeze.

Ok guys, after an endless thread of major and minor technical issues, I
suggest the following. If you want, consider this suggestion a
rule, though I would personally never ever insist on deciding here.
Anyway, I've been the most active jackd maintainer recently, so somebody
needs to step forward. ;)

We instantly switch to jackd2. End of the story.

Ok, it's not actually the end of the story, but we first make progress
and upload jackd2 to unstable. This way, our worst case scenario is
jackd2-only in squeeze. And that's better than jackd1-only.

Why? Because torbenh said so. ;) We know that jackd2 is working, and it
currently provides the one important feature required for desktop users:
pulseaudio integration, so PA and jackd can coexists without major
tweaks like ripping off PA, shutting down applications blocking the
audio device and the lot.

Torben said: If you can only have one implementation, then jackd2 is
probably the best.


Ok, so somebody will upload jackd2 within one week. This is where the
story continues...

We *then* try to support multiple jackd packages. I'm pretty sure this
will work, we've already outlined all the details, Garbiel and Torben
even hacked a prototype within 15 minutes.

If we'll be fast enough to get this into squeeze... well, I think it's
mainly copy and paste, the actual work is probably no more than one hour
for somebody who knows what he's doing (Reinhard, Jonas).


  - decide on a default implementation

jackd2.

  - allow users to switch and use a non-default implementation

Absolutely.



Cheerio

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-21 Thread Jonas Smedegaard

On Tue, Apr 20, 2010 at 07:48:26PM -0500, Gabriel M. Beddingfield wrote:


On Tue, 20 Apr 2010, Jonas Smedegaard wrote:


Let me then adjust and refine my proposal (main point is the same):

[snip]


It was suggested to discuss the introduction of the virtual 
libjack-0.116.0 on d-devel.  I consider that unnecessary as it is 
coordinated only amongst 3 packages that are all maintained by us.  
But if someone finds it relevant and


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.

Each implementation will have their own package names, and then in 
addition they will all claim to provide a _virtual_ package name called 
libjack0.100.0.  So not like earlier (which was before I got involved 
in the team, so I only know of the result, not the considerations behind 
it).


If upstream had a more strict coding style (and if I understand it 
correctly, I am a scripter myself, not a coder, so looking at it from 
aside), then they would probably instead have bumped the SONAME and we 
would not use an odd version like this but just use libjack1 as the 
tag name.


We could also use libjack-2010 or jack-lib-new-generation if those 
better indicate what is common across the implementations.  Do upstream 
perhaps have an internal codename for the unification/freeze that we 
could reuse?



Later it might make sense to try support officially linking against 
alternate implementations. If that works out, it might make sense to 
repackage jackd1 similar to the others, so as to treat all 
implementations as equal competitors.  But that is post Squeeze IMO.


An alternative to keep from holding up squeeze could be: keep things as 
they are currently... with Jack 1.  Keep Jack 2 in sid (or something) 
so users can upgrade to it if they want.  Meanwhile, the proposal 
sounds odd because of the way that the package names relate and the 
0.116.0 thing.


This is contained in my proposal: Just tag the newly added 
implementations with a dummy release-critical bugreport to keep them 
from trickling into testing and from there to stable, and you have 
things as they are currently.


What I propose goes _beyond_ that, though.  It is a no-brainer to revert 
our git to status quo, but what then?  I did not put timestamps on each 
step but it _is_ an ordered list, and if some step fail or gets stalled, 
then the affected packages will not reach Squeeze in time for the 
release.  In other words, if something (or someone - e.g. ftpmaster) 
turns out to not work right, then what will for sure stay in the archive 
and get shipped with Squeeze be jackd1.



Right now going from jack1-jack2 is a clean upgrade because of the 
version numbers... so (for me) that would be fine. This all hit the 
fan because it's hard for users to go from jack2-jack1 because they 
have to force a downgrade and the LAD list was told that squeeze 
would ship with Jack 2.


Indeed.  My proposal puts first priority on keeping what we know is 
stable (and what turns out to not be abandoned upstream after all), and 
it puts second a way to try switch not only from one implementation to 
one other (that's easy) but from a single implementation to a choice of 
multiple ones.  Not multiple ones installed concurrently, but multiple 
mutually conflicting ones available for installation concurrently.



Regards,

 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-21 Thread Reinhard Tartler
On Wed, Apr 21, 2010 at 09:45:22 (CEST), Jonas Smedegaard wrote:

 On Tue, Apr 20, 2010 at 07:48:26PM -0500, Gabriel M. Beddingfield wrote:

On Tue, 20 Apr 2010, Jonas Smedegaard wrote:

Let me then adjust and refine my proposal (main point is the same):
[snip]

 It was suggested to discuss the introduction of the virtual
 libjack-0.116.0 on d-devel.  I consider that unnecessary as it is
 coordinated only amongst 3 packages that are all maintained by us.
 But if someone finds it relevant and

 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?

If that's correct, then I didn't understand the purpose of the virtual
package name at all. My (and torben's idea AFAIU him) was to make
application packages generate dependencies on the virtual package that
indicates the promised 'stable ABI' by default, unless the package has
specific requirements on some (extended) libjack implementation. The
most prominent example of this are of course the respective jackd
implementations. In those cases, a shlibs.local overrides the default
shlibs.

 Each implementation will have their own package names, and then in
 addition they will all claim to provide a _virtual_ package name called
 libjack0.100.0.  So not like earlier (which was before I got involved
 in the team, so I only know of the result, not the considerations behind
 it).

I wasn't involved at that time either, but I guess this was done because
at that time both the ABI and API was not stable (enough or at all).

 If upstream had a more strict coding style (and if I understand it
 correctly, I am a scripter myself, not a coder, so looking at it from
 aside), then they would probably instead have bumped the SONAME and we
 would not use an odd version like this but just use libjack1 as the
 tag name.

No they wouldn't. They already track ABI very strictly which is the best
that could happen to a packager. AFAIUI, upstream is handling binary
compatibility in the best way given the circumstances.

The issue that makes the matter complicated are the different
implementations that are required (or at least supposed) to implement an
binary interface. This is packaging wise pretty unusual; versioned
provides would make things here much easier.

 We could also use libjack-2010 or jack-lib-new-generation if those
 better indicate what is common across the implementations.  Do upstream
 perhaps have an internal codename for the unification/freeze that we
 could reuse?

They refer to the binary interface as expressed by libjack version
0.116. For this reason, we invent the virtual package libjack-0.116 to
express we promise that each and every package that provides this
package name is actually binary compatible to the libjack library
version 0.116. (that's BTW the main reason why I think we need to
adjust the shlibs file and mass rebuild each and every package that
build-depends on libjack-dev).

 Later it might make sense to try support officially linking against
 alternate implementations. If that works out, it might make sense to
 repackage jackd1 similar to the others, so as to treat all
 implementations as equal competitors.  But that is post Squeeze IMO.

 An alternative to keep from holding up squeeze could be: keep things
 as they are currently... with Jack 1.  Keep Jack 2 in sid (or
 something) so users can upgrade to it if they want.  Meanwhile, the
 proposal sounds odd because of the way that the package names relate
 and the 0.116.0 thing.

 This is contained in my proposal: Just tag the newly added
 implementations with a dummy release-critical bugreport to keep them
 from trickling into testing and from there to stable, and you have
 things as they are currently.

 What I propose goes _beyond_ that, though.  It is a no-brainer to revert
 our git to status quo, but what then?  I did not put timestamps on each
 step but it _is_ an ordered list, and if some step fail or gets stalled,
 then the affected packages will not reach Squeeze in time for the
 release.  In other words, if something (or someone - e.g. ftpmaster)
 turns out to not work right, then what will for sure stay in the archive
 and get shipped with Squeeze be jackd1.

TBH, I don't understand how your approach is addressing the challenge:
Enable users to choose their jack implementation in a way that works.

I guess I need to find a counter example to show how things break.

 Right now going from jack1-jack2 is a clean upgrade because of the
 version numbers... so (for me) that would be fine. This all hit the
 fan because it's hard for users to go from jack2-jack1 because they
 have to force a downgrade and the LAD list was told that squeeze
 would ship with Jack 2.

 

Re: packaging jack...

2010-04-21 Thread Reinhard Tartler
On Tue, Apr 20, 2010 at 10:17:42 (CEST), Jonas Smedegaard wrote:

 On Sat, Apr 17, 2010 at 09:32:47PM +0200, torbenh wrote:
On Sat, Apr 17, 2010 at 09:13:34PM +0200, Jonas Smedegaard wrote:

 I propose to stick to jackd1 as the default/only library for other
 packages to rely on until the rerlease of Squeeze, and only offer
 alternative daemons (and eventually - most likely post-Squeeze - 
 alternative libraries too) if they do not interfere with that.

stop right here.
the library and the daemon are tied together.
the protocol between jackd and libjack is NOT fixed.

 Ok, my mistake.

 Let me then adjust and refine my proposal (main point is the same):

  1. Release src:jack-audio-connection-kit to unstable:
 * revert to track only jackd1

As said in my other mail, I don't think we have this option anymore.
Doing so would be like stabbing in adi's wrt. his cross-distro
coordination on jackd2.

  2. Initially release src:jackd2:
 * jackd2 conflicts/replaces/provides jackd
 * libjack0-jackd2 conflicts/replaces libjack0
 * libjack0-jackd2 provides libjack-0.116.0
 * libjack-jackd2-dev conflicts libjack-dev
 * Big fat warning to use -dev package only privately

So you propose to introduce 2 virtual packages: jackd and
libjack-0.116.0? What problem does introducing the virtual package jackd
solve?

  3. Initially release src:tchack, like jackd2
  4. Update jack-depending packages after testing that it works:
 * Add libjack-0.116.0 as fallback-dependency for libjack0

Ah, so at this point you propose to introduce a shlibs file like:

,[proposed shlibs file]
| libjack0 0 libjack0 (= 0.116) | libjack-0.116.0
`

is that correct?

How is the libjack0 package from other implementations supposed to look
like? Something like this?

Package:   libjack-jackd2-0
Provides:  libjack-0.116.0
Conflicts: libjack0

  4. Release jackd1 to experimental, with libjack0 providing   virtual
 package libjack-0.116.0
  5. Repackage jackd1 to experimental, with libjack0 providing   virtual
 package libjack0-0.116.0

what actual changes are involved in this repackaging?

  4. Release jackd1 to experimental, with libjack0 providing   virtual
 package libjack0-0.116.0

Repeated step 4? Or copy  paste mistake?


With you're proposal, I think switching from one alternative
implementation to another one won't work. For example switching from
tschack to jackd3 would break with undeclared file conflicts AFAIUI. And
my understanding of this whole hickhack was to allow users to switch
jack implementations without having to recompile packages.


(If it works) my idea would allow this; and without having each and
every implementation to declare conflicts against every existing other
implementation.


-- 
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


Re: packaging jack - details on plan B

2010-04-21 Thread Jonas Smedegaard

On Wed, Apr 21, 2010 at 12:26:41PM +0200, Reinhard Tartler wrote:

On Tue, Apr 20, 2010 at 10:17:42 (CEST), Jonas Smedegaard wrote:


On Sat, Apr 17, 2010 at 09:32:47PM +0200, torbenh wrote:

On Sat, Apr 17, 2010 at 09:13:34PM +0200, Jonas Smedegaard wrote:


I propose to stick to jackd1 as the default/only library for other 
packages to rely on until the rerlease of Squeeze, and only offer 
alternative daemons (and eventually - most likely post-Squeeze - 
alternative libraries too) if they do not interfere with that.


stop right here.
the library and the daemon are tied together.
the protocol between jackd and libjack is NOT fixed.


Ok, my mistake.

Let me then adjust and refine my proposal (main point is the same):

 1. Release src:jack-audio-connection-kit to unstable:
* revert to track only jackd1


As said in my other mail, I don't think we have this option anymore.
Doing so would be like stabbing in adi's wrt. his cross-distro
coordination on jackd2.


Switch to jackd2, no matter the costs is silly.  I propose to do our 
best to ship next distro release with jackd2 support, and do not feel 
like stabbing anyone by juggling that wording - now that the world of 
(j|ch)ack(d[12])? turned out to be more complex, post the cross-distro 
agreements.


But let us discuss strategy and implementation separately: Please do 
*not* reply to this email regarding cross-distro coordination strategy, 
but comment on my other recent email in another forked subthread. :-)




 2. Initially release src:jackd2:
* jackd2 conflicts/replaces/provides jackd
* libjack0-jackd2 conflicts/replaces libjack0
* libjack0-jackd2 provides libjack-0.116.0
* libjack-jackd2-dev conflicts libjack-dev
* Big fat warning to use -dev package only privately


So you propose to introduce 2 virtual packages: jackd and
libjack-0.116.0? What problem does introducing the virtual package jackd
solve?


 3. Initially release src:tchack, like jackd2
 4. Update jack-depending packages after testing that it works:
* Add libjack-0.116.0 as fallback-dependency for libjack0


Ah, so at this point you propose to introduce a shlibs file like:

,[proposed shlibs file]
| libjack0 0 libjack0 (= 0.116) | libjack-0.116.0
`

is that correct?


Yes, correct.

But an important detail is that I do *not* introduce that virtual 
package to the currently stable jackd1 packaging, only to newly 
introuced jackd2 and tchack packagings!


Only when proven reliable do I want to infect the stable package or 
other jack-dependent packages!


The reason for this is the logic of molding a new Debian releaase: It is 
much easier to rip out newly introduced oddities with not depended on by 
other already-accepted packages, than it is to fix problems involving 
chains of package rebuilds.


This also means we do not need to set it all in stone: we do not need to 
discuss *now* what exact wording of each shlib file or naming of virtual 
packages - only if suspected to not work at all is it relevant to 
discuss *now*, else we move faster if discussing and implementing in 
parallel.


(I do feel that you suspect the grand plan to not work at all, so do not 
want to stop the current discussion, just want to warn about it 
exploding into all sorts of details not needed to discuss ahead)




How is the libjack0 package from other implementations supposed to look
like? Something like this?

Package:   libjack-jackd2-0
Provides:  libjack-0.116.0
Conflicts: libjack0


Yes, something like that.



 4. Release jackd1 to experimental, with libjack0 providing   virtual
package libjack-0.116.0
 5. Repackage jackd1 to experimental, with libjack0 providing   virtual
package libjack0-0.116.0


what actual changes are involved in this repackaging?


This step is not needed for technical reasons but was included for 
potential political reason: not in the long term emphasize jackd1 as 
being better than the other implementations.  

If it truly is irrelevant if a jack-dependent package build against 
jackd1, jackd2 or tchack, then it might (or might not!) make sense to 
stop promoting jackd1 as the most rightous of the implementations. We 
could either just abandon the libjack0 and libjack-dev as real packages 
and only rely on virtual package names for build-dependencies of 
common-ABI-conforming projects. Or we can create a set of empty 
meta-packages e.g. libjack-abi-0.116.0 and libjack-abi-0.116.0-dev, 
depending on the implementations truly obeying the declared ABI - making 
it possible to ease transition to newer ABI if API does not change, even 
if not all implementations do not switch to that newer API at the exact 
same time (or maybe some of them not at all).


Most likely this step is long after Squeeze.  And quite probably we 
won't do this step at all. Even if completely broken, I do not see 
failure of this step to affect any of the other steps. Is it relevant to 
discuss it in detail now?




 4. Release jackd1 to experimental, with libjack0 

Re: packaging jack...

2010-04-20 Thread Jonas Smedegaard

On Sat, Apr 17, 2010 at 09:32:47PM +0200, torbenh wrote:

On Sat, Apr 17, 2010 at 09:13:34PM +0200, Jonas Smedegaard wrote:


I propose to stick to jackd1 as the default/only library for other 
packages to rely on until the rerlease of Squeeze, and only offer 
alternative daemons (and eventually - most likely post-Squeeze - 
alternative libraries too) if they do not interfere with that.


stop right here.
the library and the daemon are tied together.
the protocol between jackd and libjack is NOT fixed.


Ok, my mistake.

Let me then adjust and refine my proposal (main point is the same):

 1. Release src:jack-audio-connection-kit to unstable:
* revert to track only jackd1
 2. Initially release src:jackd2:
* jackd2 conflicts/replaces/provides jackd
* libjack0-jackd2 conflicts/replaces libjack0
* libjack0-jackd2 provides libjack-0.116.0
* libjack-jackd2-dev conflicts libjack-dev
* Big fat warning to use -dev package only privately
 3. Initially release src:tchack, like jackd2
 4. Update jack-depending packages after testing that it works:
* Add libjack-0.116.0 as fallback-dependency for libjack0

 4. Release jackd1 to experimental, with libjack0 providing 
virtual package libjack-0.116.0
 5. Repackage jackd1 to experimental, with libjack0 providing 
virtual package libjack0-0.116.0
 4. Release jackd1 to experimental, with libjack0 providing 
virtual package libjack0-0.116.0

 5. Maybe add -dev packages for jackd2 and tchack later

The main thing in above is to stick with jackd1, treating it as the 
reference implementation that other implementations match but do not 
override (they do not provide libjack-dev!).  That means no dependent 
package needs rebuilding, and rebuilds cannot accidentally shift to 
linking against another implementation with potentially different API. 
If alternate implementations turn out to not be stable enough as runtime 
drop-in replacements, they can thus be ripped out of Squeeze late in the 
game, as no other packages depend on them.


It was suggested to discuss the introduction of the virtual 
libjack-0.116.0 on d-devel.  I consider that unnecessary as it is 
coordinated only amongst 3 packages that are all maintained by us.  But 
if someone finds it relevant and have the time available to take such 
discussion then it certainly won't hurt (the only thing it hurts is 
time).


Later it might make sense to try support officially linking against 
alternate implementations. If that works out, it might make sense to 
repackage jackd1 similar to the others, so as to treat all 
implementations as equal competitors.  But that is post Squeeze IMO.



If noone objects to this proposal, I will start working on it as soon 
aas I find time (probably starting in a week from now).



 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-19 Thread Jonas Smedegaard

On Sun, Apr 18, 2010 at 09:18:06AM +0200, Reinhard Tartler wrote:

On Sat, Apr 17, 2010 at 22:07:56 (CEST), Jonas Smedegaard wrote:


On Sat, Apr 17, 2010 at 09:48:41PM +0200, Reinhard Tartler wrote:

On Sat, Apr 17, 2010 at 21:01:21 (CEST), Jonas Smedegaard wrote:


On Sat, Apr 17, 2010 at 03:25:45PM +0200, torbenh wrote:


we (upstream) will make sure they are binary compatible.
all symbols added since jack-0.116 are mandated to be weak.
if there are any issues with binary compatibility these are bugs.


Sounds like a promise of a stable API.

How about then bumping the API from 0 to 1?


if you mean the SONAME, then you would require rebuilding all 
applications for no reason. There is absolutely no need for this.


Then packages could depend unversioned on libjack1, instead of 
versioned on libjack0 = 0.116.0.


This would be terribly confusing, as it indicates that the SONAME has 
been bumped which is not the case.


I did not mean that Debian should bump SONAME, but would it not make 
sense for _upstream_ to do so when they claim their library ABI to now 
be stable?



That would make it possible to offer alternative jackd 
implementations:


Alternative implementations simply should not provide a *-dev 
package, to enforce build-depending against the main jackd 
implementation (for now that means jakcd1, might change to a 
different one in the future).


I suspect that is the simplest approach to multiple jack 
implementations in Debian.


The issue with the various flavors of the *-dev package is the least 
problem here. Moreover, it is neither necessary nor sufficient. Quite 
the contrary, I think that we need to allow multiple *-dev packages, 
because some implementation might provide some extra, optional feature 
that is only declared in an implementation specific header.


Isn't that a contradiction to the upstream claim of library ABI being 
stable since version 0.116.0, or am I missing something?



 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-19 Thread Felipe Sateler
On Mon, Apr 19, 2010 at 09:00, Jonas Smedegaard jo...@jones.dk wrote:
 On Sun, Apr 18, 2010 at 09:18:06AM +0200, Reinhard Tartler wrote:

 On Sat, Apr 17, 2010 at 22:07:56 (CEST), Jonas Smedegaard wrote:

 On Sat, Apr 17, 2010 at 09:48:41PM +0200, Reinhard Tartler wrote:

 On Sat, Apr 17, 2010 at 21:01:21 (CEST), Jonas Smedegaard wrote:

 On Sat, Apr 17, 2010 at 03:25:45PM +0200, torbenh wrote:

 we (upstream) will make sure they are binary compatible.
 all symbols added since jack-0.116 are mandated to be weak.
 if there are any issues with binary compatibility these are bugs.

 Sounds like a promise of a stable API.

 How about then bumping the API from 0 to 1?

 if you mean the SONAME, then you would require rebuilding all
 applications for no reason. There is absolutely no need for this.

 Then packages could depend unversioned on libjack1, instead of versioned
 on libjack0 = 0.116.0.

 This would be terribly confusing, as it indicates that the SONAME has been
 bumped which is not the case.

 I did not mean that Debian should bump SONAME, but would it not make sense
 for _upstream_ to do so when they claim their library ABI to now be stable?

Because SONAME bumps are for changes.

 That would make it possible to offer alternative jackd implementations:

 Alternative implementations simply should not provide a *-dev package, to
 enforce build-depending against the main jackd implementation (for now
 that means jakcd1, might change to a different one in the future).

 I suspect that is the simplest approach to multiple jack implementations
 in Debian.

 The issue with the various flavors of the *-dev package is the least
 problem here. Moreover, it is neither necessary nor sufficient. Quite the
 contrary, I think that we need to allow multiple *-dev packages, because
 some implementation might provide some extra, optional feature that is only
 declared in an implementation specific header.

 Isn't that a contradiction to the upstream claim of library ABI being stable
 since version 0.116.0, or am I missing something?

Strictly speaking, you are correct. However, applications are only
allowed to assume a subset of functions is available. The other
functions cannot be relied upon and applications must test for their
existence at runtime. So, while the exported ABI has not been stable,
the guaranteed ABI has.

But there is a point. If an application is expected to cope with
missing functions at runtime, why not at compile time too?


-- 

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-19 Thread Felipe Sateler
On Mon, Apr 19, 2010 at 10:48, Reinhard Tartler siret...@tauware.de wrote:
 On Mon, Apr 19, 2010 at 15:19:38 (CEST), Felipe Sateler wrote:

 But there is a point. If an application is expected to cope with
 missing functions at runtime, why not at compile time too?

 because the used implementation at runtime might not match the
 implementation that was used at compilation time?

That's the whole point of using weak symbols. Some jack functions are
guaranteed to exist, others aren't. The ones that aren't are weakly
linked, so the program can do:

if(some_jack_function) {
 some_jack_function(args);
}


Thus the implementations need not match at runtime.
-- 

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-18 Thread Reinhard Tartler

Puh, here goes another lengthy mail...

On Sat, Apr 17, 2010 at 20:31:46 (CEST), Felipe Sateler wrote:
 On Sat, Apr 17, 2010 at 09:25, torbenh torb...@gmx.de wrote:
 adi said that you somehow seem to believe that
 there cant be virtual packages containing libraries.

 this is not true.

 if you create debian/libjack0.shlibs
 and put
 ---
 libjack 0 WHATEVER
 

 in it, this will get installed into
 /var/libs/dpkg/info/libjack0.shlibs

 and it will result in dh_shlibs generating
 WHATEVER as a dependency when it encouters something linked against
 libjack.so.0

 so its pretty easy to make libjack0 a virtual package.
 we already have 3 implementations of jack
 which are all ABI compatible.
 and we really want users to be able to use them.


 Something like this is used for the ffmpeg package. However, for that
 to work, virtual packages are not enough. Dependencies on shared
 libraries are versioned, and versioned depends on virtual packages are
 not supported by dpkg. For this to work, we would need to have the
 names of the packages providing the alternative libraries. So, if the
 default jack is in libjack0, then there could be libjack1-0,
 libtschack0 packages that provide the different versions (and somehow
 make the versioning between all three is consistent in the shlibs
 file: libjack0 (= a.b.c) | libjack1-0 (= x.y.z) | libtschack0 (=
 f.g.h) ).

I've had a longer conversation with torben about this and my earlier
suggestion on irc. While we all agreed that from a distribution POV we
shouldn't provide more than one libjack implementation, he suggested a
further variant of the two already proposed approaches, which would
produce a shlibs file like this:

libjack0 (= a.b.c) | libjack-0.116

and the libjack-0.116 would then be a virtual package, provided by all
jack implementations. It would them indicate a provided binary
interface. All (alternative) implementations would then need to
conflict/replace on libjack-0.116. This makes libjack-0.116 effectively
a pure virtual implementation like mail-transport-agent, cf. with policy
§7.6.2. Also note that we probably should then get this discussed on
debian-devel for inclusion in the official list of virtual packages as
indicated in §3.6 and [1].

[1] http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt

I have never seen such a virtual package for shared libraries in the
wild so far. Before we do that, we would need to check if the
alternative implementations need to conflict on libjack0 explicitly, or
if conflict/providing on libjack-0.116 is sufficient.

NB: every jack daemon implementation would still need to carry a
very strict shlibs.local file to ensure that the daemon matches the
library it is compiled against!

NB2: this requires any applications with special requirements on a
specific jack implementation to ship a shlibs.local file.

 its fine if the default is jack2. but please leave the door open for
 people who have problems with jack2 and are better off with tschack.

 There is additional burden to packaging several versions of jack.
 Unless someone takes that burden and packages another version of jack,
 there is no point in making the debian package more complex. Are there
 debian packages of these other versions of jack around?

The actual packaging is not that complex. The trouble comes with
supporting/testing all possible combinations of applications and
libjack/jackd implementations.

 we (upstream) will make sure they are binary compatible.
 all symbols added since jack-0.116 are mandated to be weak.
 if there are any issues with binary compatibility these are bugs.

 I'm not sure how weak symbols help binary compatibility. If I
 understand weak symbols correctly, it enables an application to detect
 if certain symbols are available and make use of them. How does that
 ensure that an application built against one version is compatible
 with another?

It doesn't ensure anything in applications, but upstream considers such
applications buggy that need to be fixed. The weak symbol approach
isn't really supported by dpkg-shlibdeps/dpkg-gensymbols, so we need to
take special care for them.

While we are at dpkg-gensymbols: in the irc conversation, Torben said
that he considers the leaked internal symbols as something that needs to
be fixed and asked them to be reported upstream. Jonas, please keep this
in mind, and the special situation of the 0.116 ABI freeze. AFAIUI, the
current jack packages calls dh_makeshlibdeps with '-V' (i.e., without
version bound). This seems very wrong to me, and should rather be bound
to the 0.116 version, and not to each and every new upload. As for
symbol files, please reconsider the situation with these pieces of
information, I still think that symbol files don't have much benefit
without further work on hiding internal symbol, which torben seems happy
to consider for inclusion!

-- 
Gruesse/greetings,
Reinhard Tartler, 

Re: packaging jack...

2010-04-18 Thread Reinhard Tartler
On Sat, Apr 17, 2010 at 22:02:14 (CEST), Jonas Smedegaard wrote:

 I think others have tried pointing it out to me already, and it begins
 to get through my thick skull: Even if both ABI and API is compatible
 across implementations, it is _application_ ABI and API - the daemon use
 a _different API/ABI which is not set in stone so switching daemon
 forces a switch of library too.  Was that correctly summarized?

There are multiple interfaces here at runtime:

 1. application - library
 2. library - daemon

the (library) ABI is only guaranteed for level 1. different
implementations of libjack/jackd may implemented a different protocol at
level 2.

the *API* is a compile time concept. It is a fixed set of API calls and
globals that is written in stone in the jack documentation. Any
application using some internal is buggy and needs to be fixed.


PS:

Please note that commongly, ABI refers to the machine binary interface,
which only matters of you are talking about porting. For this reason,
I've already seen people that claim the ABI as discussed in this context
to be actually part of the API, with contributes to the confusion even
more!

I'd therefore suggest to talk about the library ABI, which means the
protocol between an application, the dynamic shared library loader and a
shared library at pure run-time (mostly load-time).

-- 
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


Re: packaging jack...

2010-04-18 Thread David Henningsson
Gabriel M. Beddingfield wrote:
 
 
 On Sat, 17 Apr 2010, Jonas Smedegaard wrote:
 
 stop right here.
 the library and the daemon are tied together.
 the protocol between jackd and libjack is NOT fixed.

 (basically i consider it a mistake to even have libjack and jackd in
 different packages) but it might make sense to have that.

 The separation of library and daemon is so that an application can
 link against the library without forcing the daemon to be installed:
 the JACK support might be optional for that application (without it
 being a plugin that can be packaged separately from the main application.
 
 When you register with libjack, it will start the daemon if it is not
 already running.  So, you can't have the library without the daemon.[*]

From a distribution point of view - and just to clarify what I think
Jonas is trying to say - a lot of people will need the library but not
the daemon. E g FluidSynth (and many other applications) can use both
ALSA and JACK backends, so Debian ships FluidSynth with bindings to
libjack, although many users will just use the ALSA backend. These users
will have to install libjack but not the daemon.

And just linking to libjack doesn't cause jackd to start.

// David


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-17 Thread Felipe Sateler
On Sat, Apr 17, 2010 at 09:25, torbenh torb...@gmx.de wrote:

 hi...

Hi Torben. (I'm CCing you because I don't know if you are subscribed).


 i just want to make sure you leave the option open
 to package alternative jack versions.

 adi said that you somehow seem to believe that
 there cant be virtual packages containing libraries.

 this is not true.

 if you create debian/libjack0.shlibs
 and put
 ---
 libjack 0 WHATEVER
 

 in it, this will get installed into
 /var/libs/dpkg/info/libjack0.shlibs

 and it will result in dh_shlibs generating
 WHATEVER as a dependency when it encouters something linked against
 libjack.so.0

 so its pretty easy to make libjack0 a virtual package.
 we already have 3 implementations of jack
 which are all ABI compatible.
 and we really want users to be able to use them.


Something like this is used for the ffmpeg package. However, for that
to work, virtual packages are not enough. Dependencies on shared
libraries are versioned, and versioned depends on virtual packages are
not supported by dpkg. For this to work, we would need to have the
names of the packages providing the alternative libraries. So, if the
default jack is in libjack0, then there could be libjack1-0,
libtschack0 packages that provide the different versions (and somehow
make the versioning between all three is consistent in the shlibs
file: libjack0 (= a.b.c) | libjack1-0 (= x.y.z) | libtschack0 (=
f.g.h) ).



 its fine if the default is jack2. but please leave the door open for
 people who have problems with jack2 and are better off with tschack.

There is additional burden to packaging several versions of jack.
Unless someone takes that burden and packages another version of jack,
there is no point in making the debian package more complex. Are there
debian packages of these other versions of jack around?


 we (upstream) will make sure they are binary compatible.
 all symbols added since jack-0.116 are mandated to be weak.
 if there are any issues with binary compatibility these are bugs.

I'm not sure how weak symbols help binary compatibility. If I
understand weak symbols correctly, it enables an application to detect
if certain symbols are available and make use of them. How does that
ensure that an application built against one version is compatible
with another?

-- 

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-17 Thread Jonas Smedegaard

On Sat, Apr 17, 2010 at 03:25:45PM +0200, torbenh wrote:


we (upstream) will make sure they are binary compatible.
all symbols added since jack-0.116 are mandated to be weak.
if there are any issues with binary compatibility these are bugs.


Sounds like a promise of a stable API.

How about then bumping the API from 0 to 1?

(sorry if my question is silly - I am a scripter, not a C/C++ coder)


 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-17 Thread Reinhard Tartler
On Sat, Apr 17, 2010 at 21:01:21 (CEST), Jonas Smedegaard wrote:

 On Sat, Apr 17, 2010 at 03:25:45PM +0200, torbenh wrote:

we (upstream) will make sure they are binary compatible.
all symbols added since jack-0.116 are mandated to be weak.
if there are any issues with binary compatibility these are bugs.

 Sounds like a promise of a stable API.

 How about then bumping the API from 0 to 1?

if you mean the SONAME, then you would require rebuilding all
applications for no reason. There is absolutely no need for this.

-- 
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


Re: packaging jack...

2010-04-17 Thread Jonas Smedegaard

On Sat, Apr 17, 2010 at 09:32:47PM +0200, torbenh wrote:

On Sat, Apr 17, 2010 at 09:13:34PM +0200, Jonas Smedegaard wrote:



Not an answer (as you know I am incapable of doing so), but I
propose to stick to jackd1 as the default/only library for other
packages to rely on until the rerlease of Squeeze, and only offer
alternative daemons (and eventually - most likely post-Squeeze -
alternative libraries too) if they do not interfere with that.


stop right here.
the library and the daemon are tied together.
the protocol between jackd and libjack is NOT fixed.

(basically i consider it a mistake to even have libjack and jackd in
different packages) but it might make sense to have that.


The separation of library and daemon is so that an application can link 
against the library without forcing the daemon to be installed: the JACK 
support might be optional for that application (without it being a 
plugin that can be packaged separately from the main application.




still you MUST ALWAYS lock the a jackd and libjack package together.


Thanks for the clarification.

I think others have tried pointing it out to me already, and it begins 
to get through my thick skull: Even if both ABI and API is compatible 
across implementations, it is _application_ ABI and API - the daemon use 
a _different API/ABI which is not set in stone so switching daemon 
forces a switch of library too.  Was that correctly summarized?



 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-17 Thread Jonas Smedegaard

On Sat, Apr 17, 2010 at 09:48:41PM +0200, Reinhard Tartler wrote:

On Sat, Apr 17, 2010 at 21:01:21 (CEST), Jonas Smedegaard wrote:


On Sat, Apr 17, 2010 at 03:25:45PM +0200, torbenh wrote:


we (upstream) will make sure they are binary compatible.
all symbols added since jack-0.116 are mandated to be weak.
if there are any issues with binary compatibility these are bugs.


Sounds like a promise of a stable API.

How about then bumping the API from 0 to 1?


if you mean the SONAME, then you would require rebuilding all 
applications for no reason. There is absolutely no need for this.


Then packages could depend unversioned on libjack1, instead of versioned 
on libjack0 = 0.116.0.


That would make it possible to offer alternative jackd implementations:

Alternative implementations simply should not provide a *-dev package, 
to enforce build-depending against the main jackd implementation (for 
now that means jakcd1, might change to a different one in the future).


I suspect that is the simplest approach to multiple jack implementations 
in Debian.



 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-17 Thread Gabriel M. Beddingfield



On Sat, 17 Apr 2010, Jonas Smedegaard wrote:


stop right here.
the library and the daemon are tied together.
the protocol between jackd and libjack is NOT fixed.

(basically i consider it a mistake to even have libjack and jackd in
different packages) but it might make sense to have that.


The separation of library and daemon is so that an application can link 
against the library without forcing the daemon to be installed: the JACK 
support might be optional for that application (without it being a plugin 
that can be packaged separately from the main application.


When you register with libjack, it will start the daemon if 
it is not already running.  So, you can't have the library 
without the daemon.[*]


-gabriel

[*] There is a trivial case where an application is
using libjack only for the ringbuffer implementation.
This wouldn't require the daemon, and I doubt that
any applications are /only/ using this part.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-17 Thread Gabriel M. Beddingfield



On Sat, 17 Apr 2010, Jonas Smedegaard wrote:

When you register with libjack, it will start the daemon if it is not 
already running.  So, you can't have the library without the daemon.[*]


That sounds like trouble: if such application is invoked inside a chroot, it 
causes a mess!


Debian mandates ability to enforce daemons to not be started (it is called 
policy.d - see e.g. the Debian package policyrcd-script-zg2 for more info 
(and probably somewhere in Debian Policy itself - too lazy to look it up 
right now).


jackd is not Not NOT a system daemon and should never be 
started by an rc.d script.


jackd is a user daemon that should started and stopped by a 
normal user.


-gabriel


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: packaging jack...

2010-04-17 Thread Jonas Smedegaard

On Sat, Apr 17, 2010 at 04:01:17PM -0500, Gabriel M. Beddingfield wrote:



On Sat, 17 Apr 2010, Jonas Smedegaard wrote:

When you register with libjack, it will start the daemon if it is 
not already running.  So, you can't have the library without the 
daemon.[*]


That sounds like trouble: if such application is invoked inside a 
chroot, it causes a mess!


Debian mandates ability to enforce daemons to not be started (it is 
called policy.d - see e.g. the Debian package policyrcd-script-zg2 
for more info (and probably somewhere in Debian Policy itself - too 
lazy to look it up right now).


jackd is not Not NOT a system daemon and should never be started by 
an rc.d script.


jackd is a user daemon that should started and stopped by a normal 
user.


I know it is not a system daemon.  If policy.d only is tied only to sysV 
scripts then I apologize for causing confusion: I do *not* mean to say 
that jack should be handled as a sysV system daemon.


My point is that even as a user-invoked daemon I still believe that it 
should be possible to suppress it due to being a daemon.


I believe (but have now investigated) that user dbus (in addition to 
system dbus) is can be suppressed too, for the same reason.


It has been some time since I looked at this last: When using diskless 
systems like LTSP this issue becomes relevant.



 - Jonas

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

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


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers