Gunnar Wolf wrote: > Ok, so in the end this was solved :) But still, there are many > (although not _that_ many) such bundles in the CPAN world. I think we > could follow something like: > > - The package name follows the module name (so, libtime-modules-perl > in this case). I was playing with the idea of just dropping lib > (time-modules-perl) or adding 'bundle' > (time-modules-perl-bundle)... But I don't think it adds much clarity I consider the form w/o the "lib" prefix (e.g. "time-modules-perl") a good idea for source packages. It's also useful for libraries that do provide an executable script or two, such as Mail::SPF, which I intend to package shortly (it's the successor of Mail::SPF::Query). The mail-spf-perl source package has two binary packages: libmail-spf-perl and spf-tools-perl (containing two executable scripts that use Mail::SPF). > - Make sure it does include the list of independent included modules > in its long description, so apt-cache can grok it That it should do regardless. > Now... where to draw the line on including lists of modules? (most > modules include tens of sub-modules) Is there a real distinction > between CPAN's modules and bundles? If so, that's the answer :) If it's a collection of related but independent modules, list each of them in the description. If the package name doesn't make clear immediately what packages are contained, list them. Otherwise, don't.
Attachment:
signature.asc
Description: This is a digitally signed message part.