Re: packages with perl-modules, CPAN, Policy
On Mon, 09 Jun 2008 14:42:34 +0400, Dmitry E. Oboukhov wrote: (cc to [EMAIL PROTECTED], please adjust accordingly) 1. dh-make-perl For example we build with itshelpthepackage libwww-mechanize-perl. Excellent! The package is built. But it's not a package, its a template for package! not if you use dh-make-perl's --build switch. 2. Thank you for many links on apt-cache search, but I mean rather another class of problems :) that's why you've been pointed to apt-file search :) Start the command apt-cache --full search -- -perl|less and see hoe many packages haven't the modules' names in description. I agree that that's sub-optimal. If you hit such packages IMO a whishlist bug would be appropriate. Bringing into service the possibility of the unambiguous search according to the module name will give an opportunity to improve dh-make-perl and write utilities such as I described in my first mail etc. dh-make-perl uses `apt-file search Module::Name' internally. Cheers, gregor -- .''`. http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4 : :' : debian gnu/linux user, admin developer - http://www.debian.org/ `. `' member of https://www.vibe.at/ | how to reply: http://got.to/quote/ `-BOFH excuse #94: Internet outage signature.asc Description: Digital signature
packages with perl-modules, CPAN, Policy
Thank you for many links on dh-make-perl whick you sent me privately, but for all that I mean another class of problems: 1. dh-make-perl For example we build with itshelpthepackage libwww-mechanize-perl. Excellent! The package is built. But it's not a package, its a template for package! i.e. If one tries to build it in pbuilder system, then the build will not be fulfilled successfully. Why does it happen? Because dh-make-perl left the field (Indep-)?Build-Depends empty. If there's created a unambiguous search of the package according to its name then it will be possible to introduce such an opportunity in dh-make-perl. 2. Thank you for many links on apt-cache search, but I mean rather another class of problems :) Start the command apt-cache --full search -- -perl|less and see hoe many packages haven't the modules' names in description. Thereafter there exists the complexity of search, for example one can't find libio-compress-zlib-perl according to modules' names IO::Uncompress::Gunzip, IO::Uncompress::Unzip. Besides very often a single deb-package includes many different perl modules, which are by all means not included into Description. i.e. At present it is very hard to write an utility of the search of a name of deb-package according to a name of Perl-module. Bringing into service the possibility of the unambiguous search according to the module name will give an opportunity to improve dh-make-perl and write utilities such as I described in my first mail etc. signature.asc Description: Digital signature
Re: packages with perl-modules, CPAN, Policy
This one time, at band camp, Dmitry E. Oboukhov said: Thank you for many links on dh-make-perl whick you sent me privately, but for all that I mean another class of problems: 2. Thank you for many links on apt-cache search, but I mean rather another class of problems :) Start the command apt-cache --full search -- -perl|less and see hoe many packages haven't the modules' names in description. Thereafter there exists the complexity of search, for example one can't find libio-compress-zlib-perl according to modules' names IO::Uncompress::Gunzip, IO::Uncompress::Unzip. apt-file search IO/Uncompress/Gunzip.pm apt-file search IO/Uncompress/Unzip.pm -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
packages with perl-modules, CPAN, Policy
May be I'm re-inventing the wheel, if so, please criticize. I write to the Mail List and not to BTS, may be later I'l make a post to BTS. I dislike very much to watch how the admins I'm acquainted with install perl-modules with the help of the command perl -MCPAN -e shell, however there's no other way out when the package is not included into deb-repositary. Many of them simply can't build a deb-package. Is it possible to take this work under control of the control system? I think if in the system of controlling the packages there would be an opportunity of univocal (single-valued) search of a deb-package according to the name of a perl-module [1], then it would give the following opportunity (and besides the simple ease of search of a package name (sometimes it is rather hard to find a deb-package in repository according to the name of perl-module)): it would be possible to write a script (working for example under debconf control)) with the following characteristics: 1. when refreshing of any of packages with perl-modules its call would be organized (by analogy with update-menu) 2. this script would scan the directories with the modules installed and taken from cpan and make their list 3. having a list of modules it would make a search [1] of deb-packages containing such modules and if the search is successful it would offer to install them (with the help of the blocks of debconf dialogue) 4. it would delete the modules installed from CPAN that were replaced by the modules from deb-packages. So when refreshing the system the modules installed from cpan would be replaced by the modules from deb-packages (if they've appeared). I could take up and write such a script however at first it is necessary to create a univocal search [1], and its realization (may be somebody will offer the better decision, won't he) demands to change the policy a bit. I offer to include new fields into debian/contol, for example: Export-Perl-Modules: WWW::Mechanize, WWW::Mechanize::Image, ... These fields may be filled in by hand or it is better to entrust this function to dh_perl (or a new utility of such kind). Also it would be good if the same utility installes in #DEBHELPER# section the call of a script described above, let it be called update-perl-modules. However these are the details of realization which are deserve to be discussed only after the principle decision of the question [1]: adding of a field to the debian/control file. This is the question I offer to discuss. PS: may be there are the same problems with installing the modules for other languages and may be we should discuss there not only an additional field Export-Perl-Modules, but also, for example, Export-(Python|TCL|Ruby|\w+)-Modules? I would like to subject this idea to the criticism from DDs who maintain perl-modules for Debian for a long time. I delved deeply into these problems only recently and so I may offer to solve the problems which have been already solved. Then correct me ;) Dmitry signature.asc Description: Digital signature
