Re: Naming policy for Perl modules (mass bug filing)

[Paul Wise]

On Wed, Mar 31, 2010 at 3:04 AM, Luke L  wrote:

> Philosophical question: When does this sort of thing get taken care
> of? In twenty years, will Debian (if it's still going) have myriad
> misnamed libraries? I know one can
>
> Shouldn't housecleaning like this be of higher priority, especially
> say, when a new version has just been put out? That way, maintainers
> would have months to slowly work on one package (and its associated
> reverse-dependencies) at a time.
>
> I do not know the technical constraints (no autobuild, etc), but
> consistency is a valuable trait of an operating system.

This sort of thing is automatically detectable, so there is now a
wishlist bug against lintian to detect it and warn the developer.
Unless people start ignoring lintian or new developers don't learn
that lintian exists, that should keep this problem at bay.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/q2pe13a36b31003302325h45317970r9077d31d96e65...@mail.gmail.com

Re: Naming policy for Perl modules (mass bug filing)

[Luke L]

On Tue, Mar 30, 2010 at 11:40 AM, Ansgar Burchardt  wrote:
> Hi,
>
> Ansgar Burchardt  writes:
>
>> the Debian Perl Policy asks for packages for the Foo::Bar module to be
>> named libfoo-bar-perl [1].  Some packages do not adhere to this scheme:
>>
> [...]
>>
>> Unless there are objections I will file bugs of severity "normal" in a
>> few days for these packages.
>
> The bugs are now filed with severity "wishlist" and user-tagged.
> A list can be obtained from [1].
>
> Regards,
> Ansgar
>
> [1] 
> 
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/87zl1ppxte@marvin.43-1.org
>
>

Philosophical question: When does this sort of thing get taken care
of? In twenty years, will Debian (if it's still going) have myriad
misnamed libraries? I know one can

Shouldn't housecleaning like this be of higher priority, especially
say, when a new version has just been put out? That way, maintainers
would have months to slowly work on one package (and its associated
reverse-dependencies) at a time.

I do not know the technical constraints (no autobuild, etc), but
consistency is a valuable trait of an operating system.

-- 
Luke L.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/c1775fd41003301204k21a4f8f5yf9fe76330ee4a...@mail.gmail.com

Re: Naming policy for Perl modules (mass bug filing)

[Ansgar Burchardt]

Hi,

Ansgar Burchardt  writes:

> the Debian Perl Policy asks for packages for the Foo::Bar module to be
> named libfoo-bar-perl [1].  Some packages do not adhere to this scheme:
>
[...]
>
> Unless there are objections I will file bugs of severity "normal" in a
> few days for these packages.

The bugs are now filed with severity "wishlist" and user-tagged.
A list can be obtained from [1].

Regards,
Ansgar

[1] 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zl1ppxte@marvin.43-1.org

Re: Naming policy for Perl modules (mass bug filing)

[Carlo Segre]

On Wed, 24 Mar 2010, Stéphane Glondu wrote:


Carlo Segre a écrit :

2. the ifeffit source package is contrib and cannot be built by the
autobuilders because of its build time dependence on pgplot5.

The latter is causing me much grief and needs to be solved before I work
on consistency issues.  Right now I have to build the package by hand on
whatever architectures I can get my hands on (I only have 8) and upload
all the binaries.  The package has not migrated to testing for nearly 2
years because not all the architectures are present and until this is
resolved, there is really no point since it will only languish in unstable.


Why didn't you just ask removal of binary packages on architectures that
lack up-to-date packages?



Well, it was because of the inconsistencies in the buildd systems.  Some 
would build using non-free sources, others would not.  This has now 
changed and none will.  Then there was the presence of the unofficial 
buildd network that was used to build non-free packages.  I had hoped that 
this could be used.  Now it is clear that this network is no longer 
functioning.  I will have to do precisely as you say.


Carlo

--
Carlo U. Segre -- Professor of Physics
Associate Dean for Graduate Admissions, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   se...@debian.org

Re: Naming policy for Perl modules (mass bug filing)

[Jozef Kutej]

gregor herrmann wrote:
> On Tue, 23 Mar 2010 22:04:58 +0900, Ansgar Burchardt wrote:
> Count me in.
> A consistent schema is easier for searching, for downloading
> (source|binary) package, for finding a package's bugs or PTS page,
> for "blindly" adding dependencies ...

consistent_schema++ that is for sure. on the other hand if the demand for it is
based on searching and lookup, why don't we create a script to look up any Perl
module and return the proper Debian package name for it?

besides the listed packages, there are a couple of bundles. starting with
/perl(-base|-modules)?/, /libcatalyst-modules(-extra)?-perl/, etc. there will be
always exceptions, right?

one solution is what dh-make-perl uses - the apt-file index. should not be
really complicated to extract that part in the script that will accept
Module::Name or Module/Name.pm and return Debian package name.

the other way is the script I've committed recently [1] that returns the package
names with Perl versions.

one or the other, it would be really helpful to have a tool to look for Perl
module in Debian. the "root/base" package name hides a lot of module names that
are currently hidden inside.

cheers,
Jozef


[1] http://svn.debian.org/viewsvn/pkg-perl/scripts/apt-pm/script/apt-pm


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba9e285.6060...@kutej.net

Re: Naming policy for Perl modules (mass bug filing)

[Stéphane Glondu]

Carlo Segre a écrit :
> 2. the ifeffit source package is contrib and cannot be built by the
> autobuilders because of its build time dependence on pgplot5.
> 
> The latter is causing me much grief and needs to be solved before I work
> on consistency issues.  Right now I have to build the package by hand on
> whatever architectures I can get my hands on (I only have 8) and upload
> all the binaries.  The package has not migrated to testing for nearly 2
> years because not all the architectures are present and until this is
> resolved, there is really no point since it will only languish in unstable.

Why didn't you just ask removal of binary packages on architectures that
lack up-to-date packages?


Cheers,

-- 
Stéphane


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba9d6a2.6060...@glondu.net

Re: Naming policy for Perl modules (mass bug filing)

[Carlo Segre]

On Tue, 23 Mar 2010, Ansgar Burchardt wrote:


Jozef Kutej  writes:


Ansgar Burchardt wrote:

the Debian Perl Policy asks for packages for the Foo::Bar module to be

Perl module packages *should* be named... :)


 "Non-conformance with guidelines denoted by should (or recommended)
 will generally be considered a bug, but will not necessarily render a
 package unsuitable for distribution."

I don't object to naming packages differently if there is a reason to do
so, but fail to see one for these packages (except for perlmagick which
is also the upstream name as noted by Bastien ROUCARIES [1]).



as the maintainer for one of the listed modules, I can tell you that I 
don't object to the notion of changing the name (I have often considered 
it) but for the fact that


1. it would entail a lot of changes for the packages which depend on it 
and


2. the ifeffit source package is contrib and cannot be built by the 
autobuilders because of its build time dependence on pgplot5.


The latter is causing me much grief and needs to be solved before I work 
on consistency issues.  Right now I have to build the package by hand on 
whatever architectures I can get my hands on (I only have 8) and upload 
all the binaries.  The package has not migrated to testing for nearly 2 
years because not all the architectures are present and until this is 
resolved, there is really no point since it will only languish in 
unstable.


So please go ahead and file the bug, I will consider it as wishlist until 
I can get the rest resolved.


Crankily (but not with the Perl Developers),

Carlo

--
Carlo U. Segre -- Professor of Physics
Associate Dean for Graduate Admissions, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   se...@debian.org


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1003240023590.3...@hydride.iit.edu

Re: Naming policy for Perl modules (mass bug filing)

[gregor herrmann]

On Tue, 23 Mar 2010 22:04:58 +0900, Ansgar Burchardt wrote:

> > can you list the benefits?
>  · Consistency.  I like to find packages with a name I would expect.
>Charles Plessy [2] and Philipp Kern [3] seem to agree with this.

Count me in.
A consistent schema is easier for searching, for downloading
(source|binary) package, for finding a package's bugs or PTS page,
for "blindly" adding dependencies ...
 
> > if, then a wishlist would be better. there are still functional bugs
> > [1] that need a people having some free time...
> I'm fine with that priority as well.  It is not really urgent after all.

I agree that fixing "real" (especially RC) bugs is more important but
nevertheless I'm in favour of filing bugs asking for a renaming of
the packages in question.

Cheers,
gregor
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Peter Jones: Belle


signature.asc
Description: Digital signature

Re: Naming policy for Perl modules (mass bug filing)

[Jonas Smedegaard]

On Tue, Mar 23, 2010 at 10:04:58PM +0900, Ansgar Burchardt wrote:

Jozef Kutej  writes:


Ansgar Burchardt wrote:

the Debian Perl Policy asks for packages for the Foo::Bar module to be

Perl module packages *should* be named... :)


 "Non-conformance with guidelines denoted by should (or recommended)
 will generally be considered a bug, but will not necessarily render a
 package unsuitable for distribution."

I don't object to naming packages differently if there is a reason to do
so, but fail to see one for these packages (except for perlmagick which
is also the upstream name as noted by Bastien ROUCARIES [1]).

[1] http://lists.debian.org/debian-devel/2010/03/msg00706.html


What is so special about Perlmagick?  I do not know of *any* upstream 
project named lib*-perl, so same argument would be true for most Perl 
module packages, I believe.



 - 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

Re: Naming policy for Perl modules (mass bug filing)

[Ansgar Burchardt]

Jozef Kutej  writes:

> Ansgar Burchardt wrote:
>> the Debian Perl Policy asks for packages for the Foo::Bar module to be
> Perl module packages *should* be named... :)

  "Non-conformance with guidelines denoted by should (or recommended)
  will generally be considered a bug, but will not necessarily render a
  package unsuitable for distribution."

I don't object to naming packages differently if there is a reason to do
so, but fail to see one for these packages (except for perlmagick which
is also the upstream name as noted by Bastien ROUCARIES [1]).

[1] http://lists.debian.org/debian-devel/2010/03/msg00706.html

>> I believe these modules should be renamed to have a consistent naming
>> scheme in Debian instead of using a prefix "perl-" or omitting the "lib"
>> for some packages.
>
> what should be the motivation and reasoning for spending time on this
> task? as it will require change on the package it self, all the
> packages that have it as dependency, plus an transition effort in
> order to make the upgrades work properly. can you list the benefits?

 · Consistency.  I like to find packages with a name I would expect.
   Charles Plessy [2] and Philipp Kern [3] seem to agree with this.

 · A good example.  When packages that do not live in the Debian
   archive do not adhere to the naming policy are installed, there
   are problems when Debian introduces the same Perl module [4].
   This was the reason I started looking for these packages.
   (I know that already existing packages will not cause this problem,
but they should be a good example for other people.)

[2] http://lists.debian.org/debian-perl/2010/02/msg00074.html
[3] http://lists.debian.org/debian-devel/2010/03/msg00709.html
[4] http://lists.debian.org/debian-perl/2010/02/msg00055.html

>> Unless there are objections I will file bugs of severity "normal" in a
>> few days for these packages.
>
> if, then a wishlist would be better. there are still functional bugs
> [1] that need a people having some free time...
>
> [1] http://pkg-perl.alioth.debian.org/cgi-bin/pet.cgi

I'm fine with that priority as well.  It is not really urgent after all.
And I know the PET page quite well...

Regards,
Ansgar


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5nbqjd1@marvin.43-1.org

Re: Naming policy for Perl modules (mass bug filing)

[Petter Reinholdtsen]

[Philipp Kern]
> It's consistent.  I'm always annoyed when looking for a Perl package that
> apt-cache search lib-perl doesn't turn up something but another
> search phrase might have.

I normally use 'apt-cache serach perl|grep -i ', and it almost
always give me a useful result.  I suspect it is less work for more
gain if we change the way you do searches instead of spending a lot of
time renaming packages for dubious gain.

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fl8w9jfiex@login1.uio.no

Re: Naming policy for Perl modules (mass bug filing)

[Jozef Kutej]

Ansgar Burchardt wrote:
> the Debian Perl Policy asks for packages for the Foo::Bar module to be

Perl module packages *should* be named... :)

> I believe these modules should be renamed to have a consistent naming
> scheme in Debian instead of using a prefix "perl-" or omitting the "lib"
> for some packages.

what should be the motivation and reasoning for spending time on this task? as
it will require change on the package it self, all the packages that have it as
dependency, plus an transition effort in order to make the upgrades work
properly. can you list the benefits?

> Unless there are objections I will file bugs of severity "normal" in a
> few days for these packages.

if, then a wishlist would be better. there are still functional bugs [1] that
need a people having some free time...

Cheers,
Jozef


[1] http://pkg-perl.alioth.debian.org/cgi-bin/pet.cgi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ba88aec@kutej.net

Re: Naming policy for Perl modules (mass bug filing)

[Philipp Kern]

["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2010-03-23, Jozef Kutej  wrote:
> what should be the motivation and reasoning for spending time on this task? as
> it will require change on the package it self, all the packages that have it 
> as
> dependency, plus an transition effort in order to make the upgrades work
> properly. can you list the benefits?

It's consistent.  I'm always annoyed when looking for a Perl package that
apt-cache search lib-perl doesn't turn up something but another
search phrase might have.

(Hint:  isn't always unique among the packages.)

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnhqh3qp.7qc.tr...@kelgar.0x539.de

Re: Naming policy for Perl modules (mass bug filing)

[Bastien ROUCARIES]

2010/3/23 Ansgar Burchardt :
> Hi,
>
> the Debian Perl Policy asks for packages for the Foo::Bar module to be
> named libfoo-bar-perl [1].  Some packages do not adhere to this scheme:
>
>  opalmod               → libopal-perl
>  gnuift-perl           → libgnuift-perl
>  perl-mapscript        → libmapscript-perl
>  perl-tk               → libtk-perl
>  speedy-cgi-perl       → libspeedy-cgi-perl
>  exactimage-perl       → libexactimage-perl
>  perl-ifeffit          → libifeffit-perl
>  rplay-perl            → librplay-perl
>  nfqueue-bindings-perl → libnfqueue-perl
>  perlmagick            → libimage-magick-perl

In this case perlmagick is the upstream name, but we could create an
empty package  libimage-magick-perl that will depend on  perlmagick ,
or the reverse if needed, but thename perlmagick should be kept due to
upstream naming [1].

[1] http://www.imagemagick.org/script/perl-magick.php

Bastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/195c7a901003230147u22d479abxa7889a98e9e63...@mail.gmail.com

Naming policy for Perl modules (mass bug filing)

[Ansgar Burchardt]

Hi,

the Debian Perl Policy asks for packages for the Foo::Bar module to be
named libfoo-bar-perl [1].  Some packages do not adhere to this scheme:

  opalmod   → libopal-perl
  gnuift-perl   → libgnuift-perl
  perl-mapscript→ libmapscript-perl
  perl-tk   → libtk-perl
  speedy-cgi-perl   → libspeedy-cgi-perl
  exactimage-perl   → libexactimage-perl
  perl-ifeffit  → libifeffit-perl
  rplay-perl→ librplay-perl
  nfqueue-bindings-perl → libnfqueue-perl
  perlmagick→ libimage-magick-perl

(dd-list attached below; the list is based on data from Feb 23 [2])

I believe these modules should be renamed to have a consistent naming
scheme in Debian instead of using a prefix "perl-" or omitting the "lib"
for some packages.

Unless there are objections I will file bugs of severity "normal" in a
few days for these packages.

Regards,
Ansgar

[1] 
http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-package_names
[2] http://lists.debian.org/debian-perl/2010/02/msg00062.html
Luciano Bello 
   imagemagick (U)

Alan Boudreault 
   mapserver (U)

Pierre Chifflier 
   nfqueue-bindings

Debian GIS Project 
   mapserver

Debian QA Group 
   gnuift
   rplay

ImageMagick Packaging Team 
   imagemagick

Daniel Kobras 
   imagemagick (U)

Francesco Paolo Lovergine 
   mapserver (U)

Ola Lundqvist 
   opalmod

Nelson A. de Oliveira 
   imagemagick (U)

Andreas Putzo 
   mapserver (U)

Bastien Roucariès 
   imagemagick (U)

Michael C. Schultheiss 
   perl-tk (U)

Carlo Segre 
   ifeffit

Jose Carlos Garcia Sogo 
   speedy-cgi-perl

Colin Tuckley 
   perl-tk

Niko Tyni 
   speedy-cgi-perl (U)

Jakub Wilk 
   exactimage