Re: Applications in the Perl Group
Hi all,
Frankly, not seeing any major opposition to this proposal, can we
proceed with the uploads of:
- cpanminus
- perlbrew
- starman
- twiggy
... as a start? If there are no objections, I would like to have these
uploaded this weekend-ish. :-)
Cheers,
Jonathan
On Sat, Feb 5, 2011 at 1:48 PM, Jonathan Yu <jawnsy@cpan.org> wrote:
> Hi all,
>
> First off, I don't object to the presence of applications being
> packaged and released under the Debian Perl Group. Not everything we
> package and maintain matches lib.*-perl, and rightly so.
>
> We maintain some applications like SQLFairy (sqlfairy +
> libsql-translator-perl), which have both a reusable library component,
> as well as a command-line application component.
>
> A month ago, libapp-cpanminus-perl was uploaded to the archive (it
> currently sits in NEW) as a resolution to an ITP (BTS#579147) -- see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579147
>
> However, as noted in message 15 of that bug, Christine Spang
> originally had an objection to the naming:
>
>> I'd also like to request that the package be called
>> 'cpanminus' rather than 'libapp-cpanminus-perl'. While this
>> is the default naming scheme for software from CPAN, it is
>> not required and makes no sense for the App::
>> namespace---these are meant to be standalone applications,
>> and having their package names start with 'lib' is confusing
>> and ugly.
>
> I *very much* agree with this, and don't know how it slipped by in the
> first place.
>
> As David Bremner noted on the IRC channel, it's not a big deal to ask
> ftp-master to reject the package, as it is currently sitting in NEW.
> However, the real purpose for this message is to establish a policy
> for the future.
>
> In the case of SQL Fairy:
>
> 1. A source package exists called 'sqlfairy'
> 2. Two binary packages are produced: sqlfairy (which includes the
> application parts) and libsql-translator-perl.
>
> I understand #1 is probably the result of historical reasons. But
> moving forward, here is what I would propose.
>
> Where a reusable module exists, that provides a command-line
> application (e.g. SQL::Translator/SQLFairy), we should have:
> 1. A source package called libsql-translator-perl
> 2. Produce two binary packages: sqlfairy and libsql-translator-perl
>
> Where an application exists (e.g. in the App::acme namespace), we should have:
> 1. A source package called acme
> 2. Produce a binary package called acme
> 3. If there is later some reusable component taken out of the original
> app, and distributed with the App package (e.g. other libraries now
> depend on this package), then we should also produce a
> libreusable-component-perl package.
>
> I believe the latter scenario is what actually happened with sqlfairy,
> and I guess nobody sees it worthwhile to bother getting the source
> package renamed.
>
> When I have some time, I would also like to put together an action
> plan detailing the current packages that have these issues (e.g.
> lib.*-perl packages that are also installing things in bin/). Of
> course, if anyone else might be interested in this, all the better :-)
>
> Cheers,
>
> Jonathan
>
Reply to: