Re: Comments regarding pd-arraysize_0.1-1_amd64.changes
On Nov 8, 2010, at 6:12 AM, Felipe Sateler wrote: On Mon, Nov 8, 2010 at 07:57, Jonas Smedegaard 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
On Mon, Nov 08, 2010 at 08:12:06AM -0300, Felipe Sateler wrote: On Mon, Nov 8, 2010 at 07:57, Jonas Smedegaard 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
On Mon, Nov 8, 2010 at 07:57, Jonas Smedegaard 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
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
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
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
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
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
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
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
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
On Fri, 2010-11-05 at 19:10 -0300, Felipe Sateler wrote:
> On Fri, Nov 5, 2010 at 00:51, Hans-Christoph Steiner 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
On Fri, Nov 5, 2010 at 00:51, Hans-Christoph Steiner 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
-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
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
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. - 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
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
On Fri, Nov 05, 2010 at 00:10:56 (CET), 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)
What about pd-goodies? (cf. debian-goodies, emacs-goodies-el, etc)
--
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: Comments regarding pd-arraysize_0.1-1_amd64.changes
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
Re: Comments regarding pd-arraysize_0.1-1_amd64.changes
On Thu, Nov 4, 2010 at 20:10, 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. 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
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
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
On Thu, Nov 4, 2010 at 17:15, Hans-Christoph Steiner 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
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
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
