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

[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20101108/0a0ce4c9/attachment-0001.pgp>