Re: Distribution installer that defaults to Debian? Code at github!!
On Thu, Feb 17, 2011 at 10:06:07PM -0500, Jonathan Yu wrote:
> Maybe a crazy idea here:
>
> How about a program we can use from Debian that will check if an
> appropriate Perl module can be found, and install the package, or
> alternatively, launch cpan/cpanm/cpanplus to install it?
That was my first hack.
The main issue (stated earlier by Gabor Szabo) is how we can
install Debian packages for the dependencies.
Say we want to install distribution Foo, dependent on Bar and Baz.
If we don't have libfoo-perl, we can call cpanm, but then
cpanm won't know to call apt-get to install libbar-perl
and libbaz-perl, which we *do* have.
We could transplant all of cpanm's
dependency finding functionality into our script, and then
call out to any cpan client to get what we need, but that
is as much a maintenance burden as maintaining a forked
version of cpanm.
A better solution might be to add a command-line argument to
cpanm, passing the name of a module to load that would
provide the following functions:
have_native_package($name,$version)
install_native_package($name,$version)
That would be less invasive, possibly
a better sell to cpanm maintainers, and
would make it trivial to create wrapper
scripts for different OSs.
> Maybe we can also divert cpan/cpanm/cpanplus (i.e. symlink) to this
> other program, and run the right shell after to install based on how
> it was called?
>
> The problem with this approach is that:
>
> 1. Functionality is restricted to cpanm
>
> 2. Functionality is tied directly into cpanm (and thus diverges from
> upstream, perhaps in a way they will not like, especially since it
> would increase the amount of code -- cpanm is all about minimalism)
>
> The benefits of this approach are that:
>
> 1. Normal cpanm can be called as-is
>
> 2. No fancy diversions are needed
I think some diversion will be needed if we are to
have both apt-get and cpanm available for installing
the dependencies.
Best,
Joel
> Cheers,
>
> Jonathan
>
> On Thu, Feb 17, 2011 at 9:19 PM, Joel Roth <joelz@pobox.com> wrote:
> > On Thu, Feb 17, 2011 at 02:42:29PM -0500, David Golden wrote:
> >> On Thu, Feb 17, 2011 at 2:23 PM, Joel Roth <joelz@pobox.com> wrote:
> >> https://github.com/bolangi/cpanminus-debian
> >>
> >> I get it now. I think you'll eventually want to rename it away but
> >> that's can be done later.
> >>
> >> I just want to take a minute to sketch what I think the general steps
> >> need to be:
> >>
> >> * module name -> INDEX -> package (tarball, apt, etc)
> >> * package -> DEPENDENCY ANALYSIS -> dependency modules (and then recurse)
> >> * package -> INSTALLER -> done!
> >>
> >> Different INDEX components could exist for different sources and a
> >> program could try several in order.
> >>
> >> DEPENDENCY ANALYSIS is very different for a "binary" package versus a
> >> CPAN source package, with the latter case complicated by the need to
> >> untar the package and run Makefile.PL and Build.PL and the variety of
> >> pre-conditions for configuring, testing, etc. I think cpanminus'
> >> approach is "you get everything installed" whereas CPAN tries to give
> >> you the option of installing configure/build/test dependencies
> >> temporarily only for the duration of an install session. If you avoid
> >> that and stick with the approach that all dependencies need to be
> >> installed (though checking for circularity), then life is much, much
> >> easier.
> >>
> >> And then the INSTALLER is easy for binary packages and only slightly
> >> more complicated for a CPAN distribution package in that you have to
> >> build and should test as well before installing, and for Debian, you
> >> have to decide where you want users to install modules (e.g. whether
> >> they need to run under sudo).
> >>
> >> I think if you focus on having really distinct components like that,
> >> then it's easy to stick the wrapper around them that toggles between
> >> options.
> >
> > Hi David,
> >
> > It's great that you can think of the process in the large.
> >
> > I've been piggybacking on Miyagawa's implemented vision of
> > that process, and so far my efforts have been in the small.
> > :-) At the moment, all I do is have some code that runs just
> > before cpanm installs a module. It asks:
> >
> > + do we have a debian module/version that satisfies this?
> > + if so install it with apt-get
> > + if we succeeded return true from cpanm's install routine
> > + otherwise let cpanm do what it was going to do anyway
> >
> > This doesn't necessary address the case that the
> > user supplies a URL or a path to a distribution
> > and clearly wants that source (and *not* a Debianized
> > package.)
> >
> > Due to my abilities, I'm tending to add just enough to
> > get the behaviors I want, leaving edge cases to be
> > addressed as they cause user itching, redness and
> > irritation. :-)
> >
> > I appreciate your thoughts on this, and will try to
> > incorporate them. At the moment, I'd like to do as
> > you suggest, segregate out the code I've hacked in
> > so that there could be a more pluggable way to allow
> > other installers (RPM, yum and friends) to accomplish
> > the same goals.
> >
> > Joel
> >
--
Joel Roth
Reply to: