[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Go (golang) packaging, part 2

On Tue, 05 Feb 2013 23:44:30 +0100
Hilko Bengen <bengen@debian.org> wrote:

> * Adam Borowski:
> >> The worst case scenario IMHO is some people invest a lot of time to
> >> make the Debianized-Go stuff quite divergent from upstream, people's
> >> expectations of how things behave in Go-land are broken when they
> >> access Go-via-Debian
> >
> > Just think what would happen if every single language and environment
> > would be allowed its own packaging system. This way lies madness.
> Not if there's a clear separation between the language's solution and
> dpkg-land. Mind you, almost every language already has its own packaging
> system or two. I really don't see any big deal here.

Then don't package Go at all and leave it entirely outside the realm of
dpkg - no dependencies allowed in either direction, no files created
outside /usr/local for any reason, no contamination of the apt or dpkg
cache data. If what you want is complete separation, why is there even
a long running thread on integration?

> > Yes, packaging needs to be beaten into shape, even if this goes
> > against upstream wishes.
> Just put up a boundary between dpkg and everything else. This is
> actually quite easy because Debian packages generally don't install
> anything to /usr/local. From there it's just a maatter of ensuring that
> each packaging system respects the line. And I expect that that's
> exactly what is going to happen in the case of the go(1) tool.

Then why bother discussing packaging Go if it isn't going to be
packaged, it's just going to invent it's own little ghetto
in /usr/local?

If Go wants to be packaged, it complies by the requirements of
packaging. If it wants to live the life of a hermit and disappear up
itself, that's fine but then it doesn't get the privilege of
interacting with the rest of Debian. It's just a user download.


Neil Williams

Attachment: pgp_RdzJF6De5.pgp
Description: PGP signature

Reply to: