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