Golang for Debian
Jonathan Nieder
I would like to package go for Debian (working with Ivan), so I
thought I would write for advice. A very rough version of the
package[1] works as far as "godoc --http=:6060".
A few questions:
1. Is golang ready for packaging by distributors? Is the language
definition stable enough that it would be okay for some version to get
frozen into Debian for a couple of years, or would that cause no end
of pain?
2. Do you know if anyone has tried packaging go before? Maybe there
are some existing packaging scripts to steal ideas from.
3. The DIRS list in src/pkg/Makefile does not include exp/ogle, so
“make clean” there does not clean it up. Intentional?
4. What files from $GOROOT need to be installed? From trial and error
the package currently installs
- pkg/
- doc/
- lib/codereview/, lib/godoc/
- favicon.ico
- src/pkg/runtime/cgocall.h, src/pkg/runtime/runtime.h
This is surely not enough, but on the other hand including all the
sources in minimal installations seems like too much.
5. src/make.bash and src/cmd/make.bash call clean.bash before doing
anything else, which makes testing in the large a big pain on wimpy
computers. Would it be acceptable to guard this with
“if [ "$1" = "--no-clean" ]” (and pass the parameters on)?
Thanks for writing go. So far the experience has been pleasantly
reminiscent of plan9port. I look forward to your thoughts.
Regards,
Jonathan
peterGo
> I would like to package go for Debian.
Why?
Peter
Russel Winder
> Jonathan,
>
> > I would like to package go for Debian.
>
> Why?
Because that way people running Debian and Ubuntu get to use Go via the
package management system they all use.
In many installations, if it doesn't come in via the package management
system then is doesn't come in at all.
Having Debian packages for Go is a very sensible idea.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
peterGo
> Is the language
> definition stable enough that it would be okay for some version to get
> frozen into Debian for a couple of years, or would that cause no end
> of pain?
http://golang.org/doc/devel/release.html
GoDev
http://groups.google.com/group/golang-dev
GoCI
http://groups.google.com/group/golang-checkins
How stable is the Go programming language?
Matias D'Ambrosio
> Hi,
Greetings, fellow debianite!
> I would like to package go for Debian (working with Ivan), so I
> thought I would write for advice. A very rough version of the
> package[1] works as far as "godoc --http=:6060".
>
> A few questions:
>
> 1. Is golang ready for packaging by distributors? Is the language
> definition stable enough that it would be okay for some version to get
> frozen into Debian for a couple of years, or would that cause no end
> of pain?
I think, at this point in time, it would make more sense to have it
in EXPERIMENTAL. Is there any software written in Go that would merit
inclusion in stable right now? Having a compiler & libs in stable with
no software is probably pointless.
> 2. Do you know if anyone has tried packaging go before? Maybe there
> are some existing packaging scripts to steal ideas from.
There is a package for Ubuntu somewhere, I haven't looked at it.
Cheers,
Matias D'Ambrosio
Andrew Gerrand
> 1. Is golang ready for packaging by distributors? Is the language
> definition stable enough that it would be okay for some version to get
> frozen into Debian for a couple of years, or would that cause no end
> of pain?
No.
While the language definition is pretty stable, the standard library
and tools are not. The last few releases have included library changes
that are not backwards-compatible, and that's just over a few weeks.
Freezing a particular release of Go in the Debian tree for months or
years would do damage to the project by frustrating users with
versioning issues.
So, please, don't create a Deb and submit it to the Debian project. :-)
With that said, I'm not against making Debs and RPMs. If the community
wants to make it easier for users of their favourite operating systems
to use Go, that's grand. We just don't want Go's distribution to be
retarded by bureaucratic processes. (I'm a Debian user, but I find
their ultra-conservative packaging policies frustrating.)
One of my goals for the next month is to provide official binary
distributions of Go as a tarball, so that people don't need Mercurial
or a C compiler to use Go. (I'll still include the Mercurial metadata,
though, so that people can use Mercurial at a later date to update the
distribution or submit patches.)
> 2. Do you know if anyone has tried packaging go before? Maybe there
> are some existing packaging scripts to steal ideas from.
I know someone on IRC (apologies that I can't remember who) created Go
RPMs for Fedora a while back.
> 3. The DIRS list in src/pkg/Makefile does not include exp/ogle, so
> “make clean” there does not clean it up. Intentional?
Ogle isn't ready yet, so I wouldn't worry about it for now.
> 4. What files from $GOROOT need to be installed? From trial and error
> the package currently installs
>
> - pkg/
> - doc/
> - lib/codereview/, lib/godoc/
> - favicon.ico
> - src/pkg/runtime/cgocall.h, src/pkg/runtime/runtime.h
>
> This is surely not enough, but on the other hand including all the
> sources in minimal installations seems like too much.
The entire source tree is pretty small. I'd be in favour of including
the whole thing.
> 5. src/make.bash and src/cmd/make.bash call clean.bash before doing
> anything else, which makes testing in the large a big pain on wimpy
> computers. Would it be acceptable to guard this with
> “if [ "$1" = "--no-clean" ]” (and pass the parameters on)?
You can do whatever you want on your own system. :-)
> Thanks for writing go. So far the experience has been pleasantly
> reminiscent of plan9port. I look forward to your thoughts.
Glad you like it! We're glad to have so much interest and such
talented people contributing to the project.
Andrew
Andrew Gerrand
> In many installations, if it doesn't come in via the package management
> system then is doesn't come in at all.
We're okay with this, for now.
It's a better than users having a bad experience with an old, broken version.
Andrew
Uriel
There are a few, at least some are re-built for every release:
http://go-lang.cat-v.org/packages
There you can find also a reference to .deb's for maemo.
uriel
ICeDX
http://www.pwnage.ca/?p=773
https://fedoraproject.org/wiki/Features/Go_Programming
At the very least I'd like to see it in the rawhide distro of Fedora.
This doesn't mean for sure it ends up in F14 but i'd like to try.
Why can't debian just package the compiler first, and then apps based
on that compiler later when everything is a bit more stable?
On Jul 5, 6:40 pm, Uriel <ur...@berlinblue.org> wrote:
> On Tue, Jul 6, 2010 at 12:33 AM, Andrew Gerrand <a...@golang.org> wrote:
ICeDX
release). I have patches you might like.
Andrew Gerrand
> Actually I'm attempting to do this with the Fedora 14 release.
>
> http://www.pwnage.ca/?p=773
>
> https://fedoraproject.org/wiki/Features/Go_Programming
>
> At the very least I'd like to see it in the rawhide distro of Fedora.
> This doesn't mean for sure it ends up in F14 but i'd like to try.
>
> Why can't debian just package the compiler first, and then apps based
> on that compiler later when everything is a bit more stable?
The compiler alone is not very useful without the standard libraries.
Plus, the compiler had more than a dozen bug fixes in the last release
alone.
Go's development is moving too quickly right now for most distros to keep up.
Andrew
Russel Winder
Thanks for your reply to my earlier email, I think my points here are
dealing with all the issues I see from all the emails about this. It's
a join rather than a fork :-)
On Tue, 2010-07-06 at 08:33 +1000, Andrew Gerrand wrote:
[ . . . ]
> While the language definition is pretty stable, the standard library
> and tools are not. The last few releases have included library changes
> that are not backwards-compatible, and that's just over a few weeks.
> Freezing a particular release of Go in the Debian tree for months or
> years would do damage to the project by frustrating users with
> versioning issues.
>
> So, please, don't create a Deb and submit it to the Debian project. :-)
An interesting dilema.
Debian Testing seems to be well up to date in most cases, though a
little behind the game in others (cf. only just moving to Python 2.6
last week). Debian Stable though is generally stuck with old software,
which is fine for installation that are happy to have old software. I
wonder how many installations of Debian Stable there are. I guess there
is the same issue with Fedora and RHEL. Though there are clearly many
installations of RHEL with its ancient software. Ubuntu has different
timescales but the issues are more or less the same, especially if you
use LTS versions only.
Overall I understand your worry about packaging leading to the existence
of ancient software on the vast majority of corporate systems. Python,
SCons and Bazaar are suffering exactly the problem I think you are
worrying about: how do SCons and Bazaar support Pythons 2.4 -> 3.1.
The answer is they don't. They compromise and choose their ground.
The problem is that having a language in a distribution is preparing the
ground for corporate acceptability. In the JVM milieu, if you don't
have your artefacts in the Maven repository then your system is totally
marginal. Updating is though under the control of the project: Maven
is a continuous update system. Which brings dynamism, but also chaos,
cf. "Dependency Hell". On the whole though it works surprisingly well,
despite OSGi not being the norm as yet.
> With that said, I'm not against making Debs and RPMs. If the community
> wants to make it easier for users of their favourite operating systems
> to use Go, that's grand. We just don't want Go's distribution to be
> retarded by bureaucratic processes. (I'm a Debian user, but I find
> their ultra-conservative packaging policies frustrating.)
[ . . . ]
I think this probably leads to what might be the right way forward:
ensure Go is packaged for the platforms of interest.
http://go-lang.cat-v.org/packages could be the best focus of this if it
is kept populated. If everyone knows that if they need a pre-packaged
system they go there, it is a half-way house between using Mercurial and
installing yourself and things being in the official distributions.
Mac OS X is covered by MacPorts, though eventually it would probably be
good to issue DMG installers as well.
Debian Testing is a problem child, because of Debian Stable. I guess
RHEL/Fedora come in this category.
Ubuntu has, on Launchpad, the idea of PPAs (personal package archives).
These are repositories that people can add to their /etc/apt/source.list
-- or more likely put a file in /etc/apt/source.list.d/ -- and then
they can keep up to date with whatever the latest published version is.
These repositories can be made to provide Debian and Ubuntu compatible
deb files as I understand it even though to focus is on providing for
all the supported releases of Ubuntu. This in effect creates a
continuous updates framework for Ubuntu, and possibly Debian.
Is there something similar for RPMs and Yum?
My experience with Groovy was that it was over-hyped to soon, and driven
into the quagmire of corporate use prior to proper stability. Go is
however long beyond the problems seen there, even though the semantics
of the library are rapidly changing. So apart from the generics debate
is there a language feature that acts as a blocker?
I believe that, from a technology transfer perspective, it would be
beneficial to put plans place soon for the phase change from
experimental sandpit working to corporate versioning support working.
Getting Go into Debian and Fedora is an integral part of that. Sure
there are risks, but I think they are probably worth taking.
Jonathan Nieder
Thanks for the quick and thorough feedback.
Andrew Gerrand wrote:
> The last few releases have included library changes
> that are not backwards-compatible, and that's just over a few weeks.
> Freezing a particular release of Go in the Debian tree for months or
> years would do damage to the project by frustrating users with
> versioning issues.
Noted. We can target experimental, try to get a large enough team to
update regularly, and include a release-critical bug to ensure Go
doesn’t get accidentally included in a release.
> I know someone on IRC (apologies that I can't remember who) created Go
> RPMs for Fedora a while back.
Yes, the Fedora packaging[1] includes some interesting tips for a
system integrator. I had forgotten the bash completion script and
editor support.
> The entire source tree is pretty small. I'd be in favour of including
> the whole thing.
Okay.
>> 5. src/make.bash and src/cmd/make.bash call clean.bash before doing
>> anything else, which makes testing in the large a big pain on wimpy
>> computers. Would it be acceptable to guard this with
>> “if [ "$1" = "--no-clean" ]” (and pass the parameters on)?
>
> You can do whatever you want on your own system. :-)
I was more interested in whether it sounded like a reasonable patch
to write and send. I guess there is nothing to do but try.
Regards,
Jonathan
[1] https://fedoraproject.org/wiki/Features/Go_Programming
Jonathan Nieder
> http://go-lang.cat-v.org/packages
Nice. The arch and macports scripts are both pretty thorough.
Thanks much,
Jonathan
ICeDX
Fedora on occasion has released with RC versions of some software
because they didn't want to support an old version and stable would be
released soon enough.
I don't see a problem with my go packages being in rawhide. It is the
unstable branch of Fedora. Not everything in rawhide makes it into a
stable release either so I believe it's relatively safe to have it
there (people expect rawhide stuff to break too). There will be a
Fesco meeting today to debate its inclusion in Fedora 14.
I tried to clean up the wiki page to change 'Google Go Compiler' to
'Official Go Compiler' where it makes sense.