Re: About the recent DD retirements
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.
So what's that mean if you're either developing or installing random
software?
1) ignore anything not in Debian and be hamstrung
2) use the language native packaging stuff
3) invest a lot of time skilling up on the various Debian utilities
and package it yourself (including repackaging every update)
4) invest even more time so that your packages can be included in Debian
It takes a couple of minutes to download something using pip or
npm; how long does it take to get a python or nodejs Debianized and
installable? (eg: learning that npm2deb exists, how to use it, what else
you have to do to have a package, building the package, and getting apt
access to the package -- which in turn presumably includes setting up
and distributing an archive key)
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".
There's two ways that could be achieved:
- having automated scripts pull everything from CPAN (et al), package
it as debs, and publish it
- having about 14,000 new DDs each individally maintaining 10-20
library packages
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). By my count, jessie's at
20,700 source packages in main, which is about an 11% per annum growth
rate since lenny, and indeed since sarge in 2005 [1]. If we'd stayed at
about a 35% pa growth rate since woody then we'd be at around 200k source
packages now, which I think would be the right order of magnitude for
everything that's actually buildable in CPAN, and PyPI and so on being
just an apt-get away.)
> > - 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?
> There are some external projects in this space, like sandstorm and juju.
(And that one too... Also, unless I'm mistaken neither are packaged
in Debian; apparently juju got dropped over a year and a half ago,
bug#716754)
> The wordpress wiki page seems to miss the wp-setup script that is in
> the package now.
The manpage says "For now, it's mainly for the package's internal usage
though."
> > - application isolation is a popular issue now, often solved by blatting
> > whole OS images around (VMs, docker, ...). That brings up a whole host
> > of packaging issues (how do you create the image, how do you keep it up
> > to date, how do you distribute the image)
> systemd has some great isolation features that use the same Linux
> kernel APIs as docker/etc.
>
> The GNOME folks are working on application isolation for the desktop:
>
> http://blogs.gnome.org/mclasen/2015/01/21/sandboxed-applications-for-gnome/
Why is that something "the GNOME folks" are doing, but "the Debian
folks" aren't?
If Debian's just about packaging, sandboxing applications (eg, apache
being sandboxed from postgresql, wordpress sandboxed from drupal) would
still be a really useful thing to do.
If Debian's about providing a whole OS experience (which is how I think
of it), then I'd add in the ability to sandbox a user's apps from each
other (and even sandbox their webpages from each other).
> > And, of course, I run Linux systems that aren't Debian these days --
> > I have both a phone and a tablet.
> The lifecycle for these sort of devices is too short for the Free
> Software world to realistically support them in a sane way before they
> become obsolete.
My last phone (nexus 4) lasted a bit over two years, which is longer
than my current laptop is going to last, I think, given they keycaps
are starting to fall off. My tablet gets much less use, but is about
two and a half I think.
In any event, cyanogenmod already demonstrates that the free software
world can support them.
> > Why aren't those people doing things in Debian? I claim two reasons:
> > 1) because they can make (more/any) money doing it elsewhere; and 2)
> > because Debian folks are more interested in the solved problems of the
> > 90s than the problems of today.
> It is also much more work to do things the Debian way.
In so far as that's true, it's a problem to be fixed.
Cheers,
aj
[0] http://www.modulecounts.com/
[1] https://lists.debian.org/debian-vote/2009/03/msg00312.html
Reply to: