Re: Distribution installer that defaults to Debian? Code at github!!
On Fri, Feb 18, 2011 at 09:28:22AM +0100, Jozef Kutej wrote:
> Hi Joel,
>
> another think that you should not forget about is that you never know what
> version of the module is in the Debian package. You can guess but you can be
> never be sure as module authors as really sloppy. Some have VERSION only in the
> main distribution module, some keep old version numbers around and some to make
> us even more crazy put higher version, than the distribution have, in the child
> .pm files.
Hi Jozef,
Fortunately, I haven't had to deal with this issue, yet.
> May be you will be also interested in https://github.com/jozef/Debian-Apt-PM/ no
> one was so far so don't worry if you won't ;-)
Thank you for bringing up an important psychological element
of life as a coder-artist. How do I deal with the reality
that I may spend long hours writing and then debugging some
code, that no one (including myself) may ever use.
It doesn't fit with the justification that "I'm making
something useful like a another kind of hammer."
More like "I'm making a hammer that an alien from Alpha
Centauri could hold using three tentacles to
knock away space barnacles from his ship."
Except they may not arrive here for another 230,000 years!
> The basic idea is that is is not possible to know exactly Module:Name <->
> libpackage-perl mapping. The apt-file method does a good job but the versions
> are missing. There for there is a script/dpkg-scanpmpackages that can go through
> a Debian repository, extract all .deb files (a huge job in the beginning,
> incremental afterwards) and index all .pm files that are founded there. You can
> see an example of the output here:
>
> http://pkg-perl.alioth.debian.org/~jozef-guest/pmindex/dists/squeeze/main/binary-i386/PerlPackages.bz2
>
> http://debian.meon.sk/mirror/ is not really a mirror. The "Packages*" files are
> all empty so it is safe to put it in /etc/apt/sources.list the apt will not
> complain about unknown signatures on unknown empty repositories. But when you do
> this the script/apt-pm will look through all these repositories for
> PerlPackages.bz2 and use this index to look-up Perl modules in deb packages.
> This allows the freedom to use stable/testing/unstable/local repositories based
> on the personal taste and preferences.
>
> When `apt-pm update` is run, the indexes are put to /var/cache/apt/apt-pm/ and
> to find a distribution based on module name just do:
>
> # apt-pm find Module::Build
> libmodule-build-perl_0.360700-1_all: Module::Build 0.3607
> libmodule-build-perl_0.2808.01-2_all: Module::Build 0.2808_01
> perl-modules_5.10.1-17_all: Module::Build 0.340201
>
> Note also that there are some patches
>
> patches/DhMakePerl.pm.patch # old dh-make-perl
> patches/FromCPAN.pm.patch # newer dh-make-perl (not sure how up to date)
> patches/Distribution.pm.patch # CPAN::Distribution to prefer installing deb
> over directly CPAN with `cpan`
Cool. This should be incorporated into packages.debian.org,
which comes up empty on searching for perl module names.
For now, I'm getting Foo::Bar -> libfoo-bar-perl mapping
from Debian::AptContents.
And I found that Dpkg::Version provides a way to get the
upstream distribution version number from a debian
distribution version provided by 'apt-cache policy'.
> Just to get an inspiration. I hope that cpanminus will find a clean way how to
> hook into dependency installing process so that all os types
> (Linux/Mac/Windows/...) will be able to prefer own packages over installing from
> cpan.
I don't have any particular sway over cpan/cpanplus/cpanminus, but hope I
can offer something simple enough for at least one of them to okay.
Best,
Joel
> Cheers,
> Jozef
--
Joel Roth
Reply to: