On Fri, Jan 23, 2015 at 11:51:32AM +0000, Jonathan McDowell wrote: > On Fri, Jan 23, 2015 at 10:57:55AM +0000, Anthony Towns wrote: > > 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 > > If this is being done in an automated fashion is there not a third > option? Teach apt and associated tools about the language specific > repositories. They'd do the download from CPAN or wherever, do the > conversion, and pass to dpkg. On the fly, no need to expand the archive > and no need to wait for the latest and greatest if you're that way > inclined. For extra bonus points teach cpan, gem etc to still work but > register the package + files with dpkg.
Sure, that's an option. It seems more a gentoo-style approach than a Debian style approach to me. The main drawback to my mind is that I don't think it's as feasible: - if cpan/pypi/etc change their formats and the conversion scripts need updating, it'd have to be done on every system, rather than in one place - you'd still require a build environment just to use the modules on and end-user system - your end-user system relies on multiple mirror networks all working, rather than just the debian mirror network working - modifying apt is probably harder than just writing scripts that generate debs (On the other hand, just pointing users at urls and having them download stuff has fewer potential licensing issues) > I think there are some issues with automated packaging which would mean > that you'd still want hand crafted bits, You definitely want hand-crafted bits somewhere; ideally those would go in the upstream sources. Having them in a separate git repo could work too though; though that adds another dependency if you're expecting every user to have access to it. > and there's the question of how > you pin to a "stable" version (though I think often the reason > people are pulling in from external sources is because the version in > stable simply isn't recent enough, rather than unavailable) but it'd be Yep, that's certainly a question. You might be able to automate it via dependency analysis, britney-style, or use popcon-style statistics. I don't know how you'd choose versions either; would experimental/unstable/testing/stable be enough varieties? Would they even be useful? How would you deal with developing against one version of a module versus running an app using a different version? Coinstalled packages? Containers? > kinda cool to have: > > cpan http://cpan.etla.org/ > cran http://mirrors.ebi.ac.uk/CRAN/ > > etc in /etc/apt/sources.list and have it just work. I guess my theory was more along the lines of either: deb http://http.debian.net/debian/ testing main contrib extras (with them all combined into the "extras" component, and sharing the pool with Debian main), or deb http://http.debian.net/debian-extras/ testing cpan cran pypi deb http://http.debian.net/debian-extras/ unstable cpan npm (with a separate pool/ and separated by upstream archive) Same/similar result, different behind the scenes implementation. > You could probably > treat each different source as a different suite to aid with apt > pinning (and by default preferring the Debian version rather than the > external version). With the examples above it'd be: Pin: release c=extras or Pin: release o=Debian-extras or Pin: release o=Debian-extras, c=cpan, a=unstable Cheers, aj -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150124051340.ga17...@master.debian.org
