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: