Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-12 Thread IOhannes zmölnig
On 11/12/2010 05:24 AM, Hans-Christoph Steiner wrote:
 
 On Nov 11, 2010, at 10:23 PM, Jonathan Wilkes wrote:
 
 I'm new to Debian and to linux, and have two noob questions:
 1. If package A has an abstraction that depends on an object from
 package B, is package B automatically installed when I install package
 A?
 
 If the package has the correct Depends: set, then yes.  For binary
 libraries, there are tools to do it.  For abstractions, its a manual
 process, but I suppose we could script it.

and if something was missed, it would be a bug, that you could report
and that can easily be fixed (given that a lot of packages are packaged
right now, it might be that there is too little time to check everything
manually)

 
 2. If package A has a help patch that uses an object from package
 B, is package B automatically installed when I install package A?
 
 Same as above.
 

there has been some discussion about this, and the consensus was, that
help-patch dependencies should be treated as not-hard-dependencies.
this would allow advanced users to override the dependency, e.g.
_allowing_ to install a library like pd-mapping without having to
install pd-pddp.

but in general, a user who does not want to tweak their pkg-manager
settings, will get a fully functional library.

fm,asdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread IOhannes m zmoelnig
On 2010-11-10 22:06, Roman Haefeli wrote:

 
 In the case of iemmatrix (and also zexy, which actually already is
 packaged as a multi-object-single-file library in Debian, but as a
 one-object-one-file library in Pd-extended) and assuming that there
 won't be any intelligent loader loader soon, what is the best way to go?


as upstream i would highly recommend to package it as a library.
if someone sees a need to _also_ package it as multi-file library, one
could create 2 binary packages out of the one source package.
but _please_ package iemmatrix as single-file-library until all problems
with hexloader are sorted out.

fgmnasdr
IOhannes

PS: i knew there was another library i should have packaged for debian.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread Roman Haefeli
On Thu, 2010-11-11 at 09:17 +0100, IOhannes m zmoelnig wrote:
 On 2010-11-10 22:06, Roman Haefeli wrote:
 
  
  In the case of iemmatrix (and also zexy, which actually already is
  packaged as a multi-object-single-file library in Debian, but as a
  one-object-one-file library in Pd-extended) and assuming that there
  won't be any intelligent loader loader soon, what is the best way to go?
 
 
 as upstream i would highly recommend to package it as a library.

Ok.

 if someone sees a need to _also_ package it as multi-file library,

I guess, there _is_ a need also for the multi-file library. Otherwise
patches made in Pd-extended will break. Don't know what is the best way
to achieve this. Probably something like this:

pd-iemmatrix:
generic single-file library depending on the metapackage 'pd'.

pdextended-iemmatrix:
dedicated iemmatrix package for Pd-extended, dependent on 
'pd-extendeded', compiled as one-object-per-file library.

What do you think? Does that work for everyone, Hans, IOhannes?

OTOH, i could imagine that there won't be acceptance from the
pkg-multimedia team for including the same package twice, besides the
fact that this is very ugly. But I don't see another way than this or
consciously breaking Pd-extended. 

  one
 could create 2 binary packages out of the one source package.
 but _please_ package iemmatrix as single-file-library until all problems
 with hexloader are sorted out.


 PS: i knew there was another library i should have packaged for debian.

I didn't mean to take that away from you. Before I started I wanted to
point out possible issues. 

Roman




___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread IOhannes m zmoelnig
On 2010-11-11 10:07, Roman Haefeli wrote:

 
 pd-iemmatrix:
   generic single-file library depending on the metapackage 'pd'.
 
 pdextended-iemmatrix:
   dedicated iemmatrix package for Pd-extended, dependent on 
   'pd-extendeded', compiled as one-object-per-file library.
 
 What do you think? Does that work for everyone, Hans, IOhannes?


i agree, that the prefixes should reflect the Depends: clause.
(pdextended-iemmatrix should thus 'Depend' on pd-extended)

however, i don't see, why pd-iemmatrix-multifile (this is _not_ a
proposal for a good name) should not be able to run with puredata (if
the user deliberately choses so), so one should not tie this package to
pdextended.

 OTOH, i could imagine that there won't be acceptance from the
 pkg-multimedia team for including the same package twice, besides the

this we should probably discuss on the pkg-multimedia list.

 fact that this is very ugly. But I don't see another way than this or
 consciously breaking Pd-extended. 

the question is, how much will break in reality.
people using [import iemmatrix] and consequently using [mtx_egg] will
not experience any degradation in flavour.
people wanting to use [mtx_*] with multifile have a stale flavour anyhow.

anyhow, until pd-hexloader is packaged, this discussion is quite moot
anyhow.
i don't think that switching from single-binary to multi-binary in the
package would cause much trouble.

 PS: i knew there was another library i should have packaged for debian.
 
 I didn't mean to take that away from you. Before I started I wanted to
 point out possible issues. 
 

though now i have created some ITPs for various iem-packages, including
iemmatrix ;-)

mcvasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread Roman Haefeli
On Thu, 2010-11-11 at 10:49 +0100, IOhannes m zmoelnig wrote:

 anyhow, until pd-hexloader is packaged, this discussion is quite moot
 anyhow.

I could take care of packaging hexloader, but I feel you think there are
other issues than with packaging. What are those? Is it still defunct?
Since I fixed iemmatrix in Pd-extended, I had the feeling that it works
quite well for iemmatrix.


 though now i have created some ITPs for various iem-packages, including
 iemmatrix ;-)

Good.

Roman


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread Hans-Christoph Steiner


I'm fine with whatever you want to do with iemmatrix.  I haven't used  
it, so I don't really have much input on it.


As for other libraries without aliases or hexloader needs (which is  
most), I see no reason why the Debian package should not be built with  
single_object.pd_linux.  With the libdir loader, it'll behave just  
like a multi-object.pd_linux library, and have the added bonus of  
working namespace prefixes.


.hc

On Nov 11, 2010, at 7:15 AM, Roman Haefeli wrote:


On Thu, 2010-11-11 at 10:49 +0100, IOhannes m zmoelnig wrote:


anyhow, until pd-hexloader is packaged, this discussion is quite moot
anyhow.


I could take care of packaging hexloader, but I feel you think there  
are

other issues than with packaging. What are those? Is it still defunct?
Since I fixed iemmatrix in Pd-extended, I had the feeling that it  
works

quite well for iemmatrix.


though now i have created some ITPs for various iem-packages,  
including

iemmatrix ;-)


Good.

Roman


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev





A cellphone to me is just an opportunity to be irritated wherever you  
are. - Linus Torvalds



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread Hans-Christoph Steiner


On that note, I should add that for 'iemlib' there are a number of  
libraries that depend on iemlib being built as single_object.pd_linux  
since they need namespace prefix support, for example pdmtl  
abstractions.  The same goes for zexy.  pd-zexy is currently just  
zexy.pd_linux, and some abstractions.


.hc

On Nov 11, 2010, at 2:52 PM, Hans-Christoph Steiner wrote:



I'm fine with whatever you want to do with iemmatrix.  I haven't  
used it, so I don't really have much input on it.


As for other libraries without aliases or hexloader needs (which is  
most), I see no reason why the Debian package should not be built  
with single_object.pd_linux.  With the libdir loader, it'll behave  
just like a multi-object.pd_linux library, and have the added bonus  
of working namespace prefixes.


.hc

On Nov 11, 2010, at 7:15 AM, Roman Haefeli wrote:


On Thu, 2010-11-11 at 10:49 +0100, IOhannes m zmoelnig wrote:

anyhow, until pd-hexloader is packaged, this discussion is quite  
moot

anyhow.


I could take care of packaging hexloader, but I feel you think  
there are
other issues than with packaging. What are those? Is it still  
defunct?
Since I fixed iemmatrix in Pd-extended, I had the feeling that it  
works

quite well for iemmatrix.


though now i have created some ITPs for various iem-packages,  
including

iemmatrix ;-)


Good.

Roman


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev





A cellphone to me is just an opportunity to be irritated wherever  
you are. - Linus Torvalds










Programs should be written for people to read, and only incidentally  
for machines to execute.

 - from Structure and Interpretation of Computer Programs


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread Roman Haefeli
On Thu, 2010-11-11 at 14:52 -0500, Hans-Christoph Steiner wrote:
 I'm fine with whatever you want to do with iemmatrix.  I haven't used  
 it, so I don't really have much input on it.

So I feel there is consensus about packaging iemmatrix (only) as a
multi-object library. 

 As for other libraries without aliases or hexloader needs (which is  
 most), I see no reason why the Debian package should not be built with  
 single_object.pd_linux.  With the libdir loader, it'll behave just  
 like a multi-object.pd_linux library, and have the added bonus of  
 working namespace prefixes.

Agreed.

Roman



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread Hans-Christoph Steiner


On Nov 11, 2010, at 3:54 PM, Roman Haefeli wrote:


On Thu, 2010-11-11 at 14:52 -0500, Hans-Christoph Steiner wrote:

I'm fine with whatever you want to do with iemmatrix.  I haven't used
it, so I don't really have much input on it.


So I feel there is consensus about packaging iemmatrix (only) as a
multi-object library.


I'd put it this way: I'm don't like ever packaging libs that way, but  
I don't use iemmatrix, so I won't stop you. :)


.hc


As for other libraries without aliases or hexloader needs (which is
most), I see no reason why the Debian package should not be built  
with

single_object.pd_linux.  With the libdir loader, it'll behave just
like a multi-object.pd_linux library, and have the added bonus of
working namespace prefixes.


Agreed.

Roman



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev







I have always wished for my computer to be as easy to use as my  
telephone; my wish has come true because I can no longer figure out  
how to use my telephone.  --Bjarne Stroustrup (creator of C++)



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread Jonathan Wilkes
I'm new to Debian and to linux, and have two noob questions:
1. If package A has an abstraction that depends on an object from 
package B, is package B automatically installed when I install package 
A?

2. If package A has a help patch that uses an object from package 
B, is package B automatically installed when I install package A?

-Jonathan

--- On Thu, 11/11/10, Hans-Christoph Steiner h...@at.or.at wrote:

 From: Hans-Christoph Steiner h...@at.or.at
 Subject: Re: [PD-dev] Debian packaging: multi-object/single-file libraries or 
 single-object/multiple-files libraries?
 To: Roman Haefeli reduz...@gmail.com
 Cc: pd-dev@iem.at
 Date: Thursday, November 11, 2010, 10:30 PM
 
 On Nov 11, 2010, at 3:54 PM, Roman Haefeli wrote:
 
  On Thu, 2010-11-11 at 14:52 -0500, Hans-Christoph
 Steiner wrote:
  I'm fine with whatever you want to do with
 iemmatrix.  I haven't used
  it, so I don't really have much input on it.
  
  So I feel there is consensus about packaging iemmatrix
 (only) as a
  multi-object library.
 
 I'd put it this way: I'm don't like ever packaging libs
 that way, but I don't use iemmatrix, so I won't stop you.
 :)
 
 .hc
 
  As for other libraries without aliases or
 hexloader needs (which is
  most), I see no reason why the Debian package
 should not be built with
  single_object.pd_linux.  With the libdir
 loader, it'll behave just
  like a multi-object.pd_linux library, and have the
 added bonus of
  working namespace prefixes.
  
  Agreed.
  
  Roman
  
  
  
  ___
  Pd-dev mailing list
  Pd-dev@iem.at
  http://lists.puredata.info/listinfo/pd-dev
 
 
 
 
 
 
 I have always wished for my computer to be as easy to use
 as my telephone; my wish has come true because I can no
 longer figure out how to use my telephone.  --Bjarne
 Stroustrup (creator of C++)
 
 
 ___
 Pd-dev mailing list
 Pd-dev@iem.at
 http://lists.puredata.info/listinfo/pd-dev
 


  

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-11 Thread Hans-Christoph Steiner


On Nov 11, 2010, at 10:23 PM, Jonathan Wilkes wrote:


I'm new to Debian and to linux, and have two noob questions:
1. If package A has an abstraction that depends on an object from
package B, is package B automatically installed when I install package
A?


If the package has the correct Depends: set, then yes.  For binary  
libraries, there are tools to do it.  For abstractions, its a manual  
process, but I suppose we could script it.



2. If package A has a help patch that uses an object from package
B, is package B automatically installed when I install package A?


Same as above.

.hc



-Jonathan

--- On Thu, 11/11/10, Hans-Christoph Steiner h...@at.or.at wrote:


From: Hans-Christoph Steiner h...@at.or.at
Subject: Re: [PD-dev] Debian packaging: multi-object/single-file  
libraries or single-object/multiple-files libraries?

To: Roman Haefeli reduz...@gmail.com
Cc: pd-dev@iem.at
Date: Thursday, November 11, 2010, 10:30 PM

On Nov 11, 2010, at 3:54 PM, Roman Haefeli wrote:


On Thu, 2010-11-11 at 14:52 -0500, Hans-Christoph

Steiner wrote:

I'm fine with whatever you want to do with

iemmatrix.  I haven't used

it, so I don't really have much input on it.


So I feel there is consensus about packaging iemmatrix

(only) as a

multi-object library.


I'd put it this way: I'm don't like ever packaging libs
that way, but I don't use iemmatrix, so I won't stop you.
:)

.hc


As for other libraries without aliases or

hexloader needs (which is

most), I see no reason why the Debian package

should not be built with

single_object.pd_linux.  With the libdir

loader, it'll behave just

like a multi-object.pd_linux library, and have the

added bonus of

working namespace prefixes.


Agreed.

Roman



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev







I have always wished for my computer to be as easy to use
as my telephone; my wish has come true because I can no
longer figure out how to use my telephone.  --Bjarne
Stroustrup (creator of C++)


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev













'You people have such restrictive dress for women,’ she said, hobbling  
away in three inch heels and panty hose to finish out another pink- 
collar temp pool day.  - “Hijab Scene #2, by Mohja Kahf




___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


[PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?

2010-11-10 Thread Roman Haefeli
Hi all

As you might know, a lot of the Pd libraries are being packaged for
Debian. Some of them have already been uploaded and can be installed
from unstable.

I'd like to include also the iemmatrix library. In Pd-extended, it is
bundled as a one-file-per-object library, which allows to instantiate
objects by prepending the library name (for instance:
[iemmatrix/mtx_*~]). For this to work correctly, the (still to be
packaged) hexloader is required, which must be loaded manually by the
user. 

Fact is, that we must assume that Pd-extended users already have made
patches using [prefix/objectname], which would break, if the iemmatrix
library is packaged as a multi-object-single-file library. This means,
that iemmatrix should be packaged as a one-object-per-file library. This
again means, that it should be made dependent on the hexloader loader in
order to work correctly. The problem is then, that hexloader is _not_
automatically loaded by Pd, but needs to be loaded manually by the user.
This in return would break patches created by users used to the
multi-object-per-file format of the library and don't know that they are
suddenly supposed to load the hexloader to make their patches work,
since they hadn't to do that before. Anyway, it's unfortunate to be
forced to use a certain loader, when at the same time there'd be the
possibility to have a perfectly functional library without loader (BTW:
PureDyne has always used a multi-object/single-file library format, so
there also users used to that). 

In an ideal world, the loader would be loaded automatically when needed,
so that a one-file-per-object iemmatrix could be made 'just to work the
same'(tm) as the multi-object-per-file iemmatrix. However, this would
require a special mechanism in Pd to either load all available loaders
automatically or load them when needed. From a Debian perspective,
making pd-iemmatrix dependent on pd-hexloader would suffice to make it
work out-of-the-box.

Generally speaking, an extra handling for loaders is not a bad idea.
They are not libraries in that they don't provide any functionality by
themselves and having to do an extra step to manually load a certain
loader before loading the actual library is awkward, also because the
library actually 'knows' what it needs.
But I don't have the slightiest clue who/if this is going to be
implemented.

In the case of iemmatrix (and also zexy, which actually already is
packaged as a multi-object-single-file library in Debian, but as a
one-object-one-file library in Pd-extended) and assuming that there
won't be any intelligent loader loader soon, what is the best way to go?

I appreciate any opinions on this.

Roman


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev