Re: Go (golang) packaging, part 2
On Wed, Jan 30, 2013 at 09:16:59PM +0000, Thorsten Glaser wrote:
> Meh, it’s evil, period.
Absolutely. As a user I have a nice package management system that I
know how to use and which works well. I don't need another one.
It is not the job of a language developer to invent yet another bloody
package distribution and installation system. Just because windows
doesn't have a decent way to handle software installations doesn't mean
other systems don't know how to do it well.
> That would be nice but not need integration, just replacement of
> cpan with a small script ;-)
> And, of course, having all of CPAN packaged properly. Which comes to…
I think having the useful bits done is fine, and dh-make-perl is pretty
good for the few times you want to try something that isn't already
packaged (and probably just long enough to find out it wasn't worth
using in the first place).
> … something like that. Not quite. I don’t think it’s worth the pain;
> it may be manageable for Perl, and maybe PEAR, and with even bigger
> pain maybe even pypi, but not for Ruby and similarily hostile upstreams.
Much as I like PHP, I really hate PEAR. I don't want another add on
system to manage.
> My co-developer (on the MirBSD side) benz has written a script that
> almost automates creation of a port (source package) from/for a CPAN:
> (It looks even MacPorts has adopted it!)
> Of course, it needs some manual review (and someone’d have to convert
> its output to Debian source packages, or merge it into the already
> existing dh-make-perl which also somewhat worked when I tried it), but
> it would make achieving this goal possible (and let running dpkg require
> 128 MiB of RAM or so, to fit the list of packages into it, I guess, but
> even those Amigas have that).
Poor old Amigas. Not that any of mine have enough CPU to run linux. :(