[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Distribution installer that defaults to Debian? Code at github!!



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?

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

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
>
>
>> -- David
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-perl-REQUEST@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>> Archive: [🔎] AANLkTimQxEpRfRxpvnefbpwvn=+MGNfTOMM+f6a0k+g6@mail.gmail.com">http://lists.debian.org/[🔎] AANLkTimQxEpRfRxpvnefbpwvn=+MGNfTOMM+f6a0k+g6@mail.gmail.com
>>
>
> --
> Joel Roth
>
>
> --
> To UNSUBSCRIBE, email to debian-perl-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 20110218021912.GA4851@sprite">http://lists.debian.org/[🔎] 20110218021912.GA4851@sprite
>
>


Reply to: