Re: About the recent DD retirements
Anthony Towns dijo [Fri, Jan 23, 2015 at 10:57:55AM +0000]:
> On Thu, Jan 22, 2015 at 07:02:51PM +0800, Paul Wise wrote:
> > On Thu, Jan 22, 2015 at 6:28 PM, Anthony Towns wrote:
> > > - there are "archive networks" for most programming languages these days:
> > > CPAN, CRAN, Hackage, PyPI, RubyGems, NPM, CCAN, etc. Installing
> > > software from these sources is often necessary for Debian users, but
> > > doesn't mesh well with packaged software (unlss you're a DD and can
> > > package it yourself). Since it's all free software, I don't really
> > > see why Debian doesn't have a set of automatic tools to repackage
> > > all that software, so it's all just an "apt-get" away.
> > We do: dh-make-perl, npm2deb, gem2deb, stdeb, cabal-debian etc which
> > are intended to be wrapped by debdry to eliminate much of the initial
> > packaging process.
>
> Sure, that works great if your model is "there are a few thousand pieces
> of interesting software, and a few hundred packagers, each of whom can
> maintain tens of them". But CPAN has 30k modules (~3k in Debian), CRAN
> has about 6k (~250 in Debian), Hackage has 7k (~700 packaged), PyPI has
> about 54k (2500 packaged), RubyGems has about 95k (~6000 packaged?),
> npm has about 120k (266 packaged?). [0]
>
> There's obviously a seriously long tail of stuff that's not very
> interesting to many people in those numbers, but Debian's still at least
> an order of magnitude short of any of them.
> (...)
> In an ideal world, users would just be able to say "apt-get install
> lib-whatever-perl" and have it. At worst, they might have to modify
> their apt sources explicitly to say "yes, I know there's a lot of crap
> on CPAN that doesn't necessarily receive good security updates, I know
> what I'm doing".
We have talked about this problem since long ago. I'm presently not
involved in the (great!) pkg-perl group, but back in 2007 I wrote an
article and presented this talk at the Vienna YAPC:
http://gwolf.org/files/integrating_perl_in_distro.pdf
http://gwolf.org/files/integrating_perl_in_distro_-_presentation.pdf
Around that time there was talk in the pkg-perl group about packaging
*all* of the CPAN. One of the factors that made us decide against it
is that in Debian we care about quality, not just quantity. And not
all of the available Perl modules have the same maintenance level (and
Perl is quite an exemplary community WRT their quality levels). Having
all modules packaged would mean we DDs would have to answer through
the BTS for any shortcomings in the different Perl (or Ruby, or R, or
TeX, or Hackage, or Python, or Node.js, or Drupal, or Whatnot)
modules. Hardly feasible.
> - having automated scripts pull everything from CPAN (et al), package
> it as debs, and publish it
> (...)
> But if the answer is "oh, you want to use some random nodejs package? just
> npm it into /opt. if you want there's some tools to help start you off
> in packaging it too"
>
> (Yes, I really think Debian should have 300k+ packages, including
> everything in all the language archives, no matter how special purposes
> (compare against the chiark* packages eg).
My answer to this is that... A distribution should mostly cater to
users. That means, we should target applications, not libraries. Yes,
most of us are programmers, and we are a special kind of users — But
programmers often prefer anyway working with either a particular
library version they are comfortable with, or with the bleeding edge,
or whatnot. Programmers will often look outside of the distribution,
because they will want specific bits at different points in time.
I believe it is the programmers' products (the applications) are
closer to what we should aim to package. If an application requires a
given set of dependencies we don't have yet fulfilled, we should work
on them. And yes, that might mean tweaking it so it works with the
versions of the libraries we have on the distribution — As we need to
provide an always-coherent, always-coinstallable set of packages.
By limiting our scope to what is actually wanted (i.e. by applications
that have been ITPed or RFPed, or for the *relatively few* specific
librares deemed as worth having on their own because there's an
obvious need for them, or whatnot), we can expect to keep excelling in
overall quality. If we were to open the scope to
just-about-everything, our distribution's quality would surely drop.
> > > - perhaps it's all been fixed since I last looked, but "web apps" still
> > > don't seem to be a "solved problem" to me. If you install, say,
> > > libreoffice, you run apt-get (or whatever), then you run libreoffice,
> > > and you're done. But if you want to install wordpress, you have a whole
> > > bunch of additional steps to go through [1].
> > We have a web app policy but it is fairly abandoned.
>
> Isn't that statement alone a pretty clear indication that Debian's not
> addressing the packaging problems of today?
Yes. Web apps are a subject that requires help, thought and
action. And it's one of the primary interactions many (indirect)
Debian users have with us!
Reply to: