Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-08 Thread Jonas Smedegaard

On Sun, Nov 07, 2010 at 01:57:26PM -0500, Hans-Christoph Steiner wrote:


On Nov 5, 2010, at 6:16 AM, IOhannes m zmölnig wrote:

On 11/05/2010 04:51 AM, Hans-Christoph Steiner wrote:


i'd probably go for a pd-plugins-misc (name to be discussed) 
package that distributes a number of _trivial_ 3rd party objects 
(trivial meaning, that they don't justify separate packaging)


We are really talking about libraries, plugins is not an appropriate 
word.  Are python objects plugins?  How about perl modules? Same 
idea here.


i was speaking more about the concept of lumping together different 
upstream projects than the actual name (hence the parenthesized 
comment)




As for packaging pd-arraysize together with other things, as far as I 
know, it is not Debian practice to lump together different upstream 
projects into a single package, I don't think its a good idea here 
either.




i think this is to be discussed on this list.
i don't know whether it's good practice, and esp. i don't know whether
its worse practice than creating a debian package for 2 smallish 
files.


It is not good practice, it is a special case based on the upstream 
distribution that has existed for many years.  Why exclude a useful 
package purely because its only two small files?  Shall we remove lots 
of kernel modules for the same reason/


Good practice is to package each upstream project as a separate source 
package.


But good practice isn't always sensible for Debian.  There is also the 
concern of too small packages that can easily be lumped into another one 
(due to always being needed there anyway).  An example of that is 
libcgi-application-basic-plugin-bundle-perl.


This sounds like such a special case.


(esp. in this very case, where the help-patch is fully functional 
even without pd-pddp installed; having pd-pddp only allows to have a 
clickable link in the help-patch for more information, instead of a 
(harmless) error on the pd-console)


If by fully you mean except the part of the help patch that needs 
'pddp'.  ;-P The help patch uses an object in pd-pddp. That part of 
the help patch won't work without it.




yes this is esactly what i mean by fully.

the non-working object is mainly cosmetical (in a sense that it 
directs you to further reading, but does not provide any primary 
information). you should be able to get all the information you need 
from the help-patch even with a non-functional [pddp/link] object (and 
if not, then there is a serious problem with the help-patch, as it 
means you have to resort to online documentation)


i would sugggest to use a Suggests: pd-pddp at the most.



First off, its key to mention to those not familiar with Pd: the help 
patches are fully functional scripts, not just static documentation.  
So that means if pddp/link is not available, then that aspect of the 
will not work (in this case pddp/link provides a clickable link to a 
webpage).


My question here is: why make things deliberately hostile for newbies?  
The docs should work and not throw errors when the open them.  I can 
understand using Recommends if they are installed by default with no 
user intervention. I'd prefer Depends for the above reasons.  I 
strongly disagree about using Suggests here.


Do that tiny little piece of code pull in other code too?

I proposed to _recommend_, not suggest, which means it is hostile only 
to those experts deliberately suppressing recommendations (and those 
ill-educated users suppressing recommendations by default).



 - 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: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-08 Thread IOhannes m zmoelnig
On 2010-11-07 19:57, Hans-Christoph Steiner wrote:

 i think this is to be discussed on this list.
 i don't know whether it's good practice, and esp. i don't know whether
 its worse practice than creating a debian package for 2 smallish files.
 
 It is not good practice, it is a special case based on the upstream
 distribution that has existed for many years.  Why exclude a useful
 package purely because its only two small files?  Shall we remove lots
 of kernel modules for the same reason/
 


i don't think we are in a position to remove kernel module packages or
collate them into a single one.

the usefulness of the very object we are talking about has been debated
and the conclusion is, that it is there merely for legacy reasons.

there _is_ a number of packages that bundle serveral smallish useful
scripts/macros/thingies together, regardless of authors, so it is not
that bad a practice you believe it is.

fgmasdr
IOhannes





smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-08 Thread IOhannes m zmoelnig
On 2010-11-07 19:57, Hans-Christoph Steiner wrote:

 i would sugggest to use a Suggests: pd-pddp at the most.
 
 
 First off, its key to mention to those not familiar with Pd: the help
 patches are fully functional scripts, not just static documentation.  So

yes, thanks for making the clear to our list compañeras.

 that means if pddp/link is not available, then that aspect of the will
 not work (in this case pddp/link provides a clickable link to a webpage).

which pretty much explains why i think that this is not a core component
of the help-patch, and that one could well live without it.

a lot of documentation in debian comes as pdf [*].
this documentation is fully useless without a pdf-reader. still most
packages (even if it is a separate -doc package) don't Depend on
'pdf-viewer' (as a matter of fact, most of them don't even recommend
or suggest a 'pdf-viewer').

yes, i am aware of the fact, that the help-patches are not
/usr/share/doc/-documentation, whereas most *.pdf do reside in
/usr/share/doc and that there are slightly different conditions.
however, there are packages like 'evolution-common' that do install pdf
files into /usr/share/evolution/2.30/help/ without having a single
dependency on anything pdf-related (as a matter of fact, the only
dependency relation of the package is a recommends on 'evolution').

 
 My question here is: why make things deliberately hostile for newbies? 
 The docs should work and not throw errors when the open them.  I can
 understand using Recommends if they are installed by default with no
 user intervention. I'd prefer Depends for the above reasons.  I strongly
 disagree about using Suggests here.
 

my question is: why make things deliberately hostile for non-newbies.

the big majorities of users who use [arraysize] will never look at the
help-patch, and even if they do they will either have pd-pddp
installed (because they followed the recommends/suggests), or they will
get a perfectly valid and informative help-patch with a single link not
working and they will be greeted by an error at the pd-console (because
they have chosen to live without httplinks).

please don't treat (newbie) users as if they very totally out of brains.

debian provides a way to specify hard/soft dependencies and imho they
should be used when they make sense. if you think having 3-class
dependencies is arguable, we should prabably argue this on a larger
scale e.g. on debian-devel@


anyhow, i don't insist on Suggests, Recommends is fine with me.

fgamsdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-08 Thread Roman Haefeli
On Sun, 2010-11-07 at 14:00 -0500, Hans-Christoph Steiner wrote:
 On Nov 5, 2010, at 7:01 PM, Roman Haefeli wrote:

  I'm interested to hear other opinions on this.

 pd-arraysize is a special case, not an example of how to do things.  
 There are plenty of simple packages in Debian, like simple kernel  
 modules for a very specific device.  In general packaging a single  
 simple object not a good idea, IMHO, but this one has a long legacy.
 arraysize has many uses, and is still widely used by people in their  
 patches, I use it regularly.

Now while thinking more about this, I realized why I never felt the need
for [arraysize] or any other measure to know the size of an array in the
the few years of using Pd: It's known already at any time. I can't think
of a situation where the size of an array is unknown. Actually, it is
always known, either because the table was provided a size argument or
the size was changed by loading a (sound-)file (an action that also
returns the new size, if '-resize' was used). To me this object is
basically useless. Checking the existing abstractions and help-files
using [arraysize] showed that [arraysize]  is only used in cases where
the patch author missed to keep track of the current size. I
acknowledge, though, that patching can be sometimes a lot easier with
[arraysize] under certain circumstances.

   It is also widely used in many Pd docs.   
 And many people prefer the simple syntax of typing arraysize vs  
 expr size($s1).

If you care about naming, then why don't you put [expr size($s1)] into
an abstraction called [arraysize]? I don't think [arraysize] is more
useful simply because it has a better name.

   Additionally, expr is GPL and arraysize is public  
 domain, so some people will use arraysize for that reason (i.e. a  
 proprietary app based on Pd like rjdj).

Good point.

I also checked how it is done in current releases of Pd-extended: There
[arraysize] was put into a folder called 'flatspace'. Would anything
speak against making a Debian package pd-flatspace out of all of those
externals and abstractions found in flatspace? To me it seems that this
folder is now used as a bin for an arbitrary and unrelated set of
externals and abstractions that are not part of another library or don't
fit well into another library. Why not keeping this structure also for
Debian packages? Then we would have a home for stuff like [arraysize].

Roman
 



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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-08 Thread Jonas Smedegaard

On Mon, Nov 08, 2010 at 11:21:54AM +0100, Roman Haefeli wrote:

On Sun, 2010-11-07 at 14:00 -0500, Hans-Christoph Steiner wrote:
Additionally, expr is GPL and arraysize is public domain, so some 
people will use arraysize for that reason (i.e. a proprietary app 
based on Pd like rjdj).


Good point.


Maybe so for upstream development, but irrelevant for Debian packaging, 
I believe.



 - 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: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-08 Thread Felipe Sateler
On Mon, Nov 8, 2010 at 07:57, Jonas Smedegaard d...@jones.dk wrote:
 On Mon, Nov 08, 2010 at 11:21:54AM +0100, Roman Haefeli wrote:

 On Sun, 2010-11-07 at 14:00 -0500, Hans-Christoph Steiner wrote:

 Additionally, expr is GPL and arraysize is public domain, so some people
 will use arraysize for that reason (i.e. a proprietary app based on Pd like
 rjdj).

 Good point.

 Maybe so for upstream development, but irrelevant for Debian packaging, I
 believe.

The decision of wether to package or not a piece of software certainly
must consider the license available. Note that making software
proprietary is not the only reason to avoid GPLed dependencies.


-- 

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: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-08 Thread Jonas Smedegaard

On Mon, Nov 08, 2010 at 08:12:06AM -0300, Felipe Sateler wrote:

On Mon, Nov 8, 2010 at 07:57, Jonas Smedegaard d...@jones.dk wrote:

On Mon, Nov 08, 2010 at 11:21:54AM +0100, Roman Haefeli wrote:


On Sun, 2010-11-07 at 14:00 -0500, Hans-Christoph Steiner wrote:


Additionally, expr is GPL and arraysize is public domain, so some 
people will use arraysize for that reason (i.e. a proprietary app 
based on Pd like rjdj).


Good point.


Maybe so for upstream development, but irrelevant for Debian 
packaging, I believe.


The decision of wether to package or not a piece of software certainly 
must consider the license available. Note that making software 
proprietary is not the only reason to avoid GPLed dependencies.


Please elaborate.

Also, public domain is not a license - so how would you imagine Debian 
should (re)distribute such code if not by infesting it with some more 
restrictive license than none?



 - 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: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-08 Thread Hans-Christoph Steiner


On Nov 8, 2010, at 6:12 AM, Felipe Sateler wrote:


On Mon, Nov 8, 2010 at 07:57, Jonas Smedegaard d...@jones.dk wrote:

On Mon, Nov 08, 2010 at 11:21:54AM +0100, Roman Haefeli wrote:


On Sun, 2010-11-07 at 14:00 -0500, Hans-Christoph Steiner wrote:


Additionally, expr is GPL and arraysize is public domain, so some  
people
will use arraysize for that reason (i.e. a proprietary app based  
on Pd like

rjdj).


Good point.


Maybe so for upstream development, but irrelevant for Debian  
packaging, I

believe.


The decision of wether to package or not a piece of software certainly
must consider the license available. Note that making software
proprietary is not the only reason to avoid GPLed dependencies.



All I am saying is that people decide to use libraries based on their  
license.  I've packaged public domain, BSD, LGPL, and GPL software for  
Debian at this point, it doesn't affect what I package.


I am also not saying that anyone should or shouldn't use [arraysize].   
I am saying that many people use it, and find it useful (myself  
included) and therefore I packaged it.


As for a bundle of simple Pd libs, there really aren't others like  
arraysize, so it'd likely be a bundle of one.


As for the 'flatspace' collection upstream, I think its a bad hack,  
and I plan on removing it from Pd-extended, and I won't package it.


.hc




It is convenient to imagine a power beyond us because that means we  
don't have to examine our own lives., from The Idols of  
Environmentalism, by Curtis White






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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-07 Thread Hans-Christoph Steiner


On Nov 5, 2010, at 7:01 PM, Roman Haefeli wrote:


On Fri, 2010-11-05 at 19:10 -0300, Felipe Sateler wrote:
On Fri, Nov 5, 2010 at 00:51, Hans-Christoph Steiner  
h...@at.or.at wrote:


As for packaging pd-arraysize together with other things, as far  
as I

know, it is not Debian practice to lump together different upstream
projects into a single package, I don't think its a good idea here
either.



It is perfectly acceptable, although not common. If there are more pd
objects that are small, then just bundle them together.


I just happened to read on the pd-list, that [arraysize] is actually
obsolete, since this functionality is already built into both puredata
and pd-extended: [expr size($s1)]

Personally, I don't see a point in supporting double functionality.  
And

since this library doesn't do anything else, I'd actually prefer to
completely disregard it. I don't think that keeping it alive solely  
for
the sake of not breaking existing patches with future Debian version  
is
a good reason, especially since fixing those patches is so easy. In  
this

case I value tidiness of the pd-lib space more than backward
compatibility. Better not adding it in the first place than removing  
it

afterwards.

I'm interested to hear other opinions on this.

Roman



pd-arraysize is a special case, not an example of how to do things.  
There are plenty of simple packages in Debian, like simple kernel  
modules for a very specific device.  In general packaging a single  
simple object not a good idea, IMHO, but this one has a long legacy.


arraysize has many uses, and is still widely used by people in their  
patches, I use it regularly.  It is also widely used in many Pd docs.   
And many people prefer the simple syntax of typing arraysize vs  
expr size($s1).  Additionally, expr is GPL and arraysize is public  
domain, so some people will use arraysize for that reason (i.e. a  
proprietary app based on Pd like rjdj).


.hc



Using ReBirth is like trying to play an 808 with a long stick.- 
David Zicarelli




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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-07 Thread Hans-Christoph Steiner


On Nov 5, 2010, at 6:16 AM, IOhannes m zmölnig wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/05/2010 04:51 AM, Hans-Christoph Steiner wrote:


i'd probably go for a pd-plugins-misc (name to be discussed)  
package

that distributes a number of _trivial_ 3rd party objects (trivial
meaning, that they don't justify separate packaging)


We are really talking about libraries, plugins is not an appropriate
word.  Are python objects plugins?  How about perl modules? Same  
idea

here.


i was speaking more about the concept of lumping together different
upstream projects than the actual name (hence the parenthesized  
comment)




As for packaging pd-arraysize together with other things, as far as I
know, it is not Debian practice to lump together different upstream
projects into a single package, I don't think its a good idea here
either.



i think this is to be discussed on this list.
i don't know whether it's good practice, and esp. i don't know whether
its worse practice than creating a debian package for 2 smallish  
files.


It is not good practice, it is a special case based on the upstream  
distribution that has existed for many years.  Why exclude a useful  
package purely because its only two small files?  Shall we remove lots  
of kernel modules for the same reason/



(esp. in this very case, where the help-patch is fully functional  
even

without pd-pddp installed; having pd-pddp only allows to have a
clickable link in the help-patch for more information, instead of a
(harmless) error on the pd-console)


If by fully you mean except the part of the help patch that needs
'pddp'.  ;-P  The help patch uses an object in pd-pddp. That part  
of the

help patch won't work without it.



yes this is esactly what i mean by fully.

the non-working object is mainly cosmetical (in a sense that it
directs you to further reading, but does not provide any primary
information). you should be able to get all the information you need
from the help-patch even with a non-functional [pddp/link] object (and
if not, then there is a serious problem with the help-patch, as it  
means

you have to resort to online documentation)

i would sugggest to use a Suggests: pd-pddp at the most.



First off, its key to mention to those not familiar with Pd: the help  
patches are fully functional scripts, not just static documentation.   
So that means if pddp/link is not available, then that aspect of the  
will not work (in this case pddp/link provides a clickable link to a  
webpage).


My question here is: why make things deliberately hostile for  
newbies?  The docs should work and not throw errors when the open  
them.  I can understand using Recommends if they are installed by  
default with no user intervention. I'd prefer Depends for the above  
reasons.  I strongly disagree about using Suggests here.


.hc




News is what people want to keep hidden and everything else is  
publicity.  - Bill Moyers




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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-05 Thread Roman Haefeli
On Fri, 2010-11-05 at 00:10 +0100, IOhannes m zmoelnig wrote:
 On 2010-11-04 22:51, Felipe Sateler wrote:
 
  Usage in a helpfile does not really warrant a Depends relation.
  Recommends or Suggests are better.
 
 i couldn't have said this better.
 
 (esp. in this very case, where the help-patch is fully functional even
 without pd-pddp installed; having pd-pddp only allows to have a
 clickable link in the help-patch for more information, instead of a
 (harmless) error on the pd-console)

I'm not sure if I understand correctly: The proposed solution is to have
a missing object in help-file, unless the user does a manual install of
pd-pddp? So in future Debian releases, when people open help-files
they're welcomed with error messages?

Roman



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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-05 Thread Roman Haefeli
On Fri, 2010-11-05 at 10:11 +0100, Jonas Smedegaard wrote:
 On Fri, Nov 05, 2010 at 09:41:19AM +0100, Roman Haefeli wrote:
 On Fri, 2010-11-05 at 00:10 +0100, IOhannes m zmoelnig wrote:
  On 2010-11-04 22:51, Felipe Sateler wrote:
 
   Usage in a helpfile does not really warrant a Depends relation. 
   Recommends or Suggests are better.
 
  i couldn't have said this better.
 
  (esp. in this very case, where the help-patch is fully functional 
  even without pd-pddp installed; having pd-pddp only allows to have a 
  clickable link in the help-patch for more information, instead of a 
  (harmless) error on the pd-console)
 
 I'm not sure if I understand correctly: The proposed solution is to 
 have a missing object in help-file, unless the user does a manual 
 install of pd-pddp? So in future Debian releases, when people open 
 help-files they're welcomed with error messages?
 
 Almost:
 
 In the future when advanced users - who override recommendations - open 
 help-files they're welcomed with error messages.
 
 Recommends are for things useful for most users but not all, i.e. things 
 that does not cause the core functionality of the package to fail.
 
 In the past apt-get was broken and did not respect recommends and 
 instead treating them like suggests.  This lead to the myth that 
 recommends should be avoided.
 
 Please aggressively use recommends, for the benfit of unusual uses of 
 packages.

Thanks for making this clear for me. Recommends: pd-pddp sounds good
to me.

Roman


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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-05 Thread IOhannes m zmölnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/05/2010 04:51 AM, Hans-Christoph Steiner wrote:

 i'd probably go for a pd-plugins-misc (name to be discussed) package
 that distributes a number of _trivial_ 3rd party objects (trivial
 meaning, that they don't justify separate packaging)
 
 We are really talking about libraries, plugins is not an appropriate
 word.  Are python objects plugins?  How about perl modules? Same idea
 here.

i was speaking more about the concept of lumping together different
upstream projects than the actual name (hence the parenthesized comment)

 
 As for packaging pd-arraysize together with other things, as far as I
 know, it is not Debian practice to lump together different upstream
 projects into a single package, I don't think its a good idea here
 either.
 

i think this is to be discussed on this list.
i don't know whether it's good practice, and esp. i don't know whether
its worse practice than creating a debian package for 2 smallish files.



 (esp. in this very case, where the help-patch is fully functional even
 without pd-pddp installed; having pd-pddp only allows to have a
 clickable link in the help-patch for more information, instead of a
 (harmless) error on the pd-console)
 
 If by fully you mean except the part of the help patch that needs
 'pddp'.  ;-P  The help patch uses an object in pd-pddp. That part of the
 help patch won't work without it.
 

yes this is esactly what i mean by fully.

the non-working object is mainly cosmetical (in a sense that it
directs you to further reading, but does not provide any primary
information). you should be able to get all the information you need
from the help-patch even with a non-functional [pddp/link] object (and
if not, then there is a serious problem with the help-patch, as it means
you have to resort to online documentation)

i would sugggest to use a Suggests: pd-pddp at the most.

fmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzT2YwACgkQkX2Xpv6ydvR78QCgy6Dwxe2xUmcIh1oic7v8KVPs
NTYAn2nqLR1Je9pVy+eR4IVT7SmaYIqu
=cyVG
-END PGP SIGNATURE-

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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-05 Thread Felipe Sateler
On Fri, Nov 5, 2010 at 00:51, Hans-Christoph Steiner h...@at.or.at wrote:
 On Fri, 2010-11-05 at 00:10 +0100, IOhannes m zmoelnig wrote:
 On 2010-11-04 22:51, Felipe Sateler wrote:

  Yeah, it is annoying for sure.  The problem is that this particular object
  is widely used and has been distributed and used like this since 2003ish.
 
  Can't it be distributed within puredata itself?

 hmm, i'd rather have the puredata package follow the upstream package
  pd as closely as possible, without adding objects.
 so people using pd-vanilla (that is: upstream pd without any
 additional libraries), are 100% compatible with people using only
 debian's puredata package.

 i'd probably go for a pd-plugins-misc (name to be discussed) package
 that distributes a number of _trivial_ 3rd party objects (trivial
 meaning, that they don't justify separate packaging)

 We are really talking about libraries, plugins is not an appropriate
 word.  Are python objects plugins?  How about perl modules? Same idea
 here.

 As for packaging pd-arraysize together with other things, as far as I
 know, it is not Debian practice to lump together different upstream
 projects into a single package, I don't think its a good idea here
 either.


It is perfectly acceptable, although not common. If there are more pd
objects that are small, then just bundle them together.
-- 

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: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-05 Thread Roman Haefeli
On Fri, 2010-11-05 at 19:10 -0300, Felipe Sateler wrote:
 On Fri, Nov 5, 2010 at 00:51, Hans-Christoph Steiner h...@at.or.at wrote:

  As for packaging pd-arraysize together with other things, as far as I
  know, it is not Debian practice to lump together different upstream
  projects into a single package, I don't think its a good idea here
  either.
 
 
 It is perfectly acceptable, although not common. If there are more pd
 objects that are small, then just bundle them together.

I just happened to read on the pd-list, that [arraysize] is actually
obsolete, since this functionality is already built into both puredata
and pd-extended: [expr size($s1)]

Personally, I don't see a point in supporting double functionality. And
since this library doesn't do anything else, I'd actually prefer to
completely disregard it. I don't think that keeping it alive solely for
the sake of not breaking existing patches with future Debian version is
a good reason, especially since fixing those patches is so easy. In this
case I value tidiness of the pd-lib space more than backward
compatibility. Better not adding it in the first place than removing it
afterwards.

I'm interested to hear other opinions on this.

Roman
   


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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-04 Thread Roman Haefeli
On Thu, 2010-11-04 at 13:03 +, Luca Falavigna wrote:
 Hi,
 
 quoting from your debian/copyright:
 License: This code is too trivial to have a licence or copyright.
 
 Is it really necessary to distribute it in a standalone source package?

Yeah, I also think that this is questionable. I'm not the right person
to make decisions, but my opinion is that we (Pd people) should take the
chance now that we're pushing Pd libraries to Debian to try to make it
as clean as possible, i.e. try not to clutter the pd-lib space with too
many trivial single-object libraries. Since the code is so trivial that
it's not even worth being covered by a license, why not incorporating
into an existing library, hcs for instance? 

On an unrelated note: the help-file contains an object [pddp/pddplink],
but pd-array does not depend on a pd-pddp (which does not yet exist).
Personally, I think that the link in the help-file does not justify to
pull another dependency in, which is otherwise not necessary for
pd-arraysize to work properly at all. Unless we agree to make pddp a
standard within help-files, I'd propose to get rid of pddp links in
help-files of debianized Pd libraries.


Roman


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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-04 Thread Hans-Christoph Steiner


On Nov 4, 2010, at 9:34 AM, Roman Haefeli wrote:


On Thu, 2010-11-04 at 13:03 +, Luca Falavigna wrote:

Hi,

quoting from your debian/copyright:
   License: This code is too trivial to have a licence or copyright.

Is it really necessary to distribute it in a standalone source  
package?


Yeah, I also think that this is questionable. I'm not the right person
to make decisions, but my opinion is that we (Pd people) should take  
the

chance now that we're pushing Pd libraries to Debian to try to make it
as clean as possible, i.e. try not to clutter the pd-lib space with  
too
many trivial single-object libraries. Since the code is so trivial  
that

it's not even worth being covered by a license, why not incorporating
into an existing library, hcs for instance?


Yeah, it is annoying for sure.  The problem is that this particular  
object is widely used and has been distributed and used like this  
since 2003ish.


On an unrelated note: the help-file contains an object [pddp/ 
pddplink],

but pd-array does not depend on a pd-pddp (which does not yet exist).
Personally, I think that the link in the help-file does not justify to
pull another dependency in, which is otherwise not necessary for
pd-arraysize to work properly at all. Unless we agree to make pddp a
standard within help-files, I'd propose to get rid of pddp links in
help-files of debianized Pd libraries.



Thanks for the bug report.  I'm ready to submit pd-pddp to Debian, so  
that'll happen soon.  Then I'll add the pd-pddp dependency to pd- 
arraysize.  If you have the time, please file a bug report, but I also  
have it on my personal TODO list.


.hc



I spent 33 years and four months in active military service and during  
that period I spent most of my time as a high class muscle man for Big  
Business, for Wall Street and the bankers.  - General Smedley Butler




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


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-04 Thread Felipe Sateler
On Thu, Nov 4, 2010 at 17:15, Hans-Christoph Steiner h...@at.or.at wrote:

 On Nov 4, 2010, at 9:34 AM, Roman Haefeli wrote:

 On Thu, 2010-11-04 at 13:03 +, Luca Falavigna wrote:

 Hi,

 quoting from your debian/copyright:
   License: This code is too trivial to have a licence or copyright.

 Is it really necessary to distribute it in a standalone source package?

 Yeah, I also think that this is questionable. I'm not the right person
 to make decisions, but my opinion is that we (Pd people) should take the
 chance now that we're pushing Pd libraries to Debian to try to make it
 as clean as possible, i.e. try not to clutter the pd-lib space with too
 many trivial single-object libraries. Since the code is so trivial that
 it's not even worth being covered by a license, why not incorporating
 into an existing library, hcs for instance?

 Yeah, it is annoying for sure.  The problem is that this particular object
 is widely used and has been distributed and used like this since 2003ish.

Can't it be distributed within puredata itself?


 On an unrelated note: the help-file contains an object [pddp/pddplink],
 but pd-array does not depend on a pd-pddp (which does not yet exist).
 Personally, I think that the link in the help-file does not justify to
 pull another dependency in, which is otherwise not necessary for
 pd-arraysize to work properly at all. Unless we agree to make pddp a
 standard within help-files, I'd propose to get rid of pddp links in
 help-files of debianized Pd libraries.


 Thanks for the bug report.  I'm ready to submit pd-pddp to Debian, so
 that'll happen soon.  Then I'll add the pd-pddp dependency to pd-arraysize.
  If you have the time, please file a bug report, but I also have it on my
 personal TODO list.

Usage in a helpfile does not really warrant a Depends relation.
Recommends or Suggests are better.


-- 

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: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-04 Thread IOhannes m zmoelnig
On 2010-11-04 22:51, Felipe Sateler wrote:

 Yeah, it is annoying for sure.  The problem is that this particular object
 is widely used and has been distributed and used like this since 2003ish.
 
 Can't it be distributed within puredata itself?

hmm, i'd rather have the puredata package follow the upstream package
 pd as closely as possible, without adding objects.
so people using pd-vanilla (that is: upstream pd without any
additional libraries), are 100% compatible with people using only
debian's puredata package.

i'd probably go for a pd-plugins-misc (name to be discussed) package
that distributes a number of _trivial_ 3rd party objects (trivial
meaning, that they don't justify separate packaging)

 
 Usage in a helpfile does not really warrant a Depends relation.
 Recommends or Suggests are better.

i couldn't have said this better.

(esp. in this very case, where the help-patch is fully functional even
without pd-pddp installed; having pd-pddp only allows to have a
clickable link in the help-patch for more information, instead of a
(harmless) error on the pd-console)

mfasdr
IOhannes



smime.p7s
Description: S/MIME Cryptographic Signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers


Re: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-04 Thread Jonas Smedegaard

On Fri, Nov 05, 2010 at 12:10:56AM +0100, IOhannes m zmoelnig wrote:
i'd probably go for a pd-plugins-misc (name to be discussed) package 
that distributes a number of _trivial_ 3rd party objects (trivial 
meaning, that they don't justify separate packaging)


pd-plugins-common perhaps?


  - 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: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-04 Thread Felipe Sateler
On Thu, Nov 4, 2010 at 20:10, IOhannes m zmoelnig zmoel...@iem.at wrote:
 On 2010-11-04 22:51, Felipe Sateler wrote:

 Yeah, it is annoying for sure.  The problem is that this particular object
 is widely used and has been distributed and used like this since 2003ish.

 Can't it be distributed within puredata itself?

 hmm, i'd rather have the puredata package follow the upstream package
  pd as closely as possible, without adding objects.
 so people using pd-vanilla (that is: upstream pd without any
 additional libraries), are 100% compatible with people using only
 debian's puredata package.

Of course. I meant including it upstream.

-- 

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: Comments regarding pd-arraysize_0.1-1_amd64.changes

2010-11-04 Thread Hans-Christoph Steiner
On Fri, 2010-11-05 at 00:10 +0100, IOhannes m zmoelnig wrote:
 On 2010-11-04 22:51, Felipe Sateler wrote:
 
  Yeah, it is annoying for sure.  The problem is that this particular object
  is widely used and has been distributed and used like this since 2003ish.
  
  Can't it be distributed within puredata itself?
 
 hmm, i'd rather have the puredata package follow the upstream package
  pd as closely as possible, without adding objects.
 so people using pd-vanilla (that is: upstream pd without any
 additional libraries), are 100% compatible with people using only
 debian's puredata package.
 
 i'd probably go for a pd-plugins-misc (name to be discussed) package
 that distributes a number of _trivial_ 3rd party objects (trivial
 meaning, that they don't justify separate packaging)

We are really talking about libraries, plugins is not an appropriate
word.  Are python objects plugins?  How about perl modules? Same idea
here.

As for packaging pd-arraysize together with other things, as far as I
know, it is not Debian practice to lump together different upstream
projects into a single package, I don't think its a good idea here
either.

.hc

 
  
  Usage in a helpfile does not really warrant a Depends relation.
  Recommends or Suggests are better.
 
 i couldn't have said this better.
 
 (esp. in this very case, where the help-patch is fully functional even
 without pd-pddp installed; having pd-pddp only allows to have a
 clickable link in the help-patch for more information, instead of a
 (harmless) error on the pd-console)

If by fully you mean except the part of the help patch that needs
'pddp'.  ;-P  The help patch uses an object in pd-pddp. That part of the
help patch won't work without it.

.hc



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