On Wed, Jun 03, 2009 at 05:44:44PM -0700, Don Armstrong wrote:
> On Wed, 03 Jun 2009, Ryan Niebur wrote:
> > On Wed, Jun 03, 2009 at 08:26:25AM -0700, Don Armstrong wrote:
> > > Or more difficult if you expect it to follow the perl policy. [It
> > > also means that you have to special case padre plugin dependencies
> > > when you're looking for them.]
> >
> > following perl policy isn't a reason to do something imo. perl
> > policy is (correctly) not followed in some other situations.
>
> If the policy is wrong, bugs should be filed, and it should be
> changed.
>
App::* (whiff, ack-grep, etc), and even Padre itself..
> > and one time I followed this part of perl policy and later (after it
> > was uploaded, oops, that will be a mess to clean up, if I ever do..)
> > got told I was wrong.
>
> By whom and in what case?
>
libapp-nopaste-perl should have been named nopaste. This was pointed
out to us by some CPAN developer (Alias, maybe?)..iirc we quickly
discussed it in #debian-perl and people generally agreed that it
should be called nopaste.
> > I don't want to make that mistake again, so I no longer strictly
> > follow this part of perl policy. wrt special casing looking for
> > depends, no need to do that, dh-make-perl does this all
> > automatically for us.
>
> Except when you're a human being looking for them.
>
run "dh-make-perl --locate Padre::Plugin::Foo", and it will tell you
padre-plugin-foo. This is the way that people should know to do things
because there are usually many different things in one package, and
only one of them has the package named after it.
> > the padre-plugin-* package naming form makes much more sense imho,
> > and it looks better. a user would probably think it's strange to
> > install libpadre-plugin-foo-perl, and that package name makes no
> > sense (other than "because perl policy says to do that", which most
> > users won't even know about). for normal cpan dists, it does make
> > sense.
>
> The entire point of the naming policy is to have a consistent naming
> scheme for all perl packages which provide modules. Violating it
> should only be done in cases where there is a significant issue with
> following the policy, and aesthetics ("looks better") don't really
> qualify as a significant issue.
>
you don't even need to know that this provides perl modules. for
things that are actually intended to be used as perl modules in perl
scripts, I understand this, but for App::* and Padre::Plugin::* this
is not true. for all the user knows (and cares), it could put stuff in
/usr/share/padre/ (tho it doesn't..). The only usecase of these
packages is that (for example) somebody ran "apt-get install padre"
and wants to have an HTML validation plugin for padre. So it only
seems logical that "apt-get install padre-plugin-html" is how you
accomplish this. Why would it be lipadre-plugin-html-perl be what
provides the plugin? I'm thinking what makes sense from a user
perspective, which imho is more important than some policy that people
already don't follow. if this were something that was actually
followed by *everything*, and I was trying to break the rule that
*everything* else followed, well, then I wouldn't be doing that. :)
and I see no technical differences (other than saving a few bytes :))
in naming it differently.
--
_________________________
Ryan Niebur
ryanryan52@gmail.com
Attachment:
signature.asc
Description: Digital signature