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

Re: Bringing CPAN,Gems, PIP, PyPi, etc. under APT package management



songbird wrote: 
> Keith Christian wrote:
> > Are there any methods to create Debian packages for these (and
> > similar) package tools (and the files they install) so that Debian's
> > native packaging system has "inventory control" everything?
> >
> > I realize that software has been installed outside of APT's purview
> > since the beginnings of Debian, but I wonder if there is any effort to
> > corral these other packaging systems so APT can be the tool of choice
> > for all package management.
> 
>   no, and i sure hope not!  do you know how many packages
> are in those?
> 
>   PyPI is a few hundred thousand items.  CPAN i don't know
> know, same with ruby or go.
> 
>   if you're doing that then you might as well toss github,
> gitlab and salsa in there too.
> 
>   i repeat myself please don't!
> 
>   should be going the other way instead.  and i mean by that
> that Debian is duplicating efforts that could be better spent
> on other things instead.  once a language or system is set up
> to figure out it's own dependencies why duplicate that effort?
> 
>   the more that is removed from the dependency chain is an
> improvement for future freezes and getting transitions done
> faster.

There are good reasons for doing this on a local basis.

For example, let's say you have an organization that develops
a software service and sells access to it. When an engineer asks 
for a particular library, it turns out to be a really good idea
to immediately turn it into a Debian package so that you can
keep the same version all the way through the chain to
production.

Many of the language-specific tools have a tendency to
automatically acquire the latest version of a library or module
every time they are invoked, or to spit errors if they can't
pull down the version that they were asked to get. That's rather
troublesome.

Having a local apt repository with all the versions of a
library that you've actually used, so you can re-deploy an old
one exactly the way it was or install a fixed version across
a set of machines is very, very useful.

As long as the tools exist to take a language's
libraries/modules/packages and turn them into a Debian package
exist, all the rest of the infrastructure is already in place.
There's no real need to try to pre-package all of CPAN, CRAN, 
CTAN, Ruby Gems, pypi...  

-dsr-


Reply to: