Re: Distribution installer that defaults to Debian?
On Fri, Dec 24, 2010 at 05:29:35PM +0200, Damyan Ivanov wrote:
> -=| Joel Roth, Wed, Dec 22, 2010 at 01:00:09PM -1000 |=-
> > On Mon, Dec 20, 2010 at 02:13:07PM +0200, Gabor Szabo wrote:
> > > It would be nice to see this on CPAN to encourage distributions to
> > > implement the same.
(...)
> > Then, what about a name?
> >
> > CPAN::NativePackageInstaller::Debian
> >
> > CPAN::Installer::Debian
> >
> > Debian::CPAN::HybridInstaller
> >
> > Would there be any benefit to prefixing App:: ?
>
> Hm, would that be extended to support other distributions than
> Debian? If yes, having the generic code (including the detection of
> the distribution-specific module to load) in a generic module, and
> distribution specific code in corresponding module may be wanted.
>
> CPAN::HybridInstaller - generic code
> CPAN::HybridInstaller::Debian, CPAN::HybridInstaller::Fedora etc.
Seems like a suitably inclusive approach.
Makes me wonder: Do other distributions/OSs go to as much
trouble as Debian in providing native packaging for perl
distributions?
btw, I found two tools for detecting the OS:
Linux::Distribution
Pfacter::operatingsystem
> > The script might be named 'dcpan', easy to type and remember
> >
> > > I also wonder if it could be integrated into CPAN.pm (and friends)
> > > itself so if I type
> > >
> > > cpan Module::Name it will install dependencies using apt-get - if
> > > possible and using cpan (with local::lib)
> > > otherwise.
> >
> > I think this would work at the top level, where
> > the user is not constraining the version number.
>
> "Plugging" this recursively in cpan or another tool would be the
> cherry of the icecream. Top-level is OK, but if you install something
> with lots of dependencies the gain will not be that big.
Seems worth aiming for, at least to code so that
the same library used for a simple top-level script,
could also be incorporated into a cpan installer.
> > The harder problem is the dependency case you mentioned.
> >
> > > BTW what happens if a secondary dependency is available as a
> > > .deb package ? I mean if I am installing package X which
> > > depends on Y which in turn depends on W and only W is in
> > > .deb X and Y are not. Will your script notice this situation
> > > and install W using apt-get ?
> >
> > Say Y requires W (>=0.5), but the corresponding Debian
> > libw-perl is only 0.4.
> >
> > It seems we can't reliably extract the upstream version from the
> > Debian package metadata. An enhanced CPAN client might
> > work around this limitation by:
> >
> > - installing the Debian package for W
> > - seeing if Y's dependency is met
> > - falling back to installing W from CPAN.
>
> It seems to me that this would work reliably, at the expense of the
> possibility of unnecessarily installing packaged modules.
> I was thinking about the version problem, and I think it is possible
> to reach a sufficiently good approach:
>
> 1) strip epoch (s/^\d+://)
> 2) strip revision (s/-[^-]$//)
> 3) strip repackaging suffix (s/[+.](?:dfsg|ds)\.?\d*$)
That's reasonable. I came up with using the regex from
the Perl::Version docs to grab the perlish part of the
version.
qr/ ( (?i: Revision: \s+ ) | v | )
( \d+ (?: [.] \d+)* )
( (?: _ \d+ )? ) /x;
> 4) what is left should be suitable for feeding version.pm and then
> comparing with the wanted version. If the version of the
> package was mangled, this is most likely 1.23 -> 1.2300
> extension, which is irrelevant to version.pm (AIUI).
> or
> 5) compare what is left with the wanted version using *dpkg*
> version comparison functions (available somewhere in the Dpkg::
> namespace). If the version was mangled, the debian-extracted
> version should compare greater than the wanted version, which
> would work for the purpose of deciding "is the package
> sufficiently new".
>
> Finally, there is a caveat with @INC, that I am not sure how to
> address. Thing is, 'cpan' installs packages in /usr/local, and
> Debian's perl has that path before /usr in @INC. I guess local::lib
> does something similar. The problem is that once you install a module
> there, it will take precedencde and will always be used regardles of
> the fact that there may be a Debian package installed which has
> a greater version. So once you install a module not using the package
> manager, you have to either upgrade it when needed or uninstall it and
> use the packaged one.
Yes I thought of this, too.
I just discovered that cpanplus has an uninstall command.
Maybe that would help to remove a module in /usr/local
or a local::lib when installing a more recent Debian package.
Thanks for your suggestions and reviewing the script.
Joel
--
Joel Roth
Reply to: