Hi Gregor and Jonathan On Sat, Feb 12, 2011 at 05:57:11PM +0100, gregor herrmann wrote: > On Sat, 05 Feb 2011 13:48:44 -0500, Jonathan Yu wrote: > > > However, the real purpose for this message is to establish a policy > > for the future. > > Thanks for bringing this up and driving it further. > > I have no strong opinions here, but I see the point of treating > more-app-than-lib packages differently. What I'd like to have is a > clear and simple policy so I know what I have to do :) > > Looking at http://wiki.debian.org/DebianPerlGroup/OpenTasks/Applications > it seems the rules could be: > > 1) For packages providing libs and scripts: > - source package libfoo-perl > - binary package libfoo-perl > provides: foo > (or optional: additional binary package foo) > for well-known/important/... tools > > 2) For applications (App::Foo): > - source package foo > - binary package foo > - (optional: binary package libfoo/something-perl if there are > libs that can be reused) > > Am I reading this correctly? > > If yes, I'm ok with it, and hope that others are quicker to share > their opinions than I was :) > > And then someone would have to propose a good wording and a patch for > website/policy.pod. > > (And maybe Debian Perl Policy 4.2, unless we don't to go that way is > 1) above doesn't change anything and 2) maybe doesn't apply?) If so I'm too perfectly fine with changing our policy to do so. We have only to keep in mind too that not all of the App::foo modules should be renamed to 'foo'. some examples which came to my mind were libapp-cmd-perl or libapp-control-perl, libapp-daemon-perl, libapp-options-perl. Indeed for libapp-nopaste-perl this would make sense. Bests Salvatore
Attachment:
signature.asc
Description: Digital signature