[pkg-golang-devel] putting the go version in the package names

Wed Mar 16 00:35:07 UTC 2016

On 15 March 2016 at 23:21, Matthias Klose <doko at ubuntu.com> wrote:
> [not sure if I already sent this one]
>
>
> On 09.03.2016 04:02, Michael Hudson-Doyle wrote:
>>
>> On 8 March 2016 at 22:31, Matthias Klose <doko at ubuntu.com> wrote:
>>>
>>> On 08.03.2016 02:29, Michael Hudson-Doyle wrote:
>>>>
>>>>
>>>> I have made some packages along these lines at
>>>> https://launchpad.net/~mwhudson/+archive/ubuntu/coinstallable-go. Are
>>>> there any upgrade scenarios I should test? I've done some simple
>>>> things.
>>>>
>>>> I'd like to get this into 16.04, so all comments appreciated!
>>>>
>>>> Cheers,
>>>> mwh
>>>>
>>>> On 2 March 2016 at 21:23, Michael Hudson-Doyle
>>>> <michael.hudson at canonical.com> wrote:
>>>>>
>>>>>
>>>>> On 16 February 2016 at 11:18, Tianon Gravi <tianon at debian.org> wrote:
>>>>>>
>>>>>>
>>>>>> On 11 February 2016 at 16:41, Steve Langasek
>>>>>> <steve.langasek at canonical.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> My $.02 here: alternatives for different toolchain versions are evil;
>>>>>>> don't
>>>>>>> use them.  You'll notice that the compilers and interpreters in
>>>>>>> Debian
>>>>>>> for
>>>>>>> most other languages don't use alternatives, but instead have a
>>>>>>> concept
>>>>>>> of a
>>>>>>> "defaults" package that points the user at the currently supported
>>>>>>> version
>>>>>>> (gcc-defaults, python-defaults, python3-defaults, default-jre,
>>>>>>> ruby-defaults... the list goes on).  The reason this is important is
>>>>>>> that
>>>>>>> the interpreter path is a critical interface for package building;
>>>>>>> having
>>>>>>> the contents of that interface vary based not on what your package
>>>>>>> specifies
>>>>>>> in its build-depends / depends, but on what other packages the admin
>>>>>>> happens
>>>>>>> to have installed and/or happens to have toggled with
>>>>>>> update-alternatives,
>>>>>>> or even what some *other* build-dependency of yours happens to depend
>>>>>>> on,
>>>>>>> would make the whole system very fragile.  You don't want maintainers
>>>>>>> to
>>>>>>> have to hard-code 'go-1.6' everywhere in their code just to make sure
>>>>>>> they
>>>>>>> don't get go-1.5, and then have to update their source again once
>>>>>>> go-1.7 is
>>>>>>> out and becomes the default!
>>>
>>>
>>>
>>> default-jre is somehow different in that it still uses alternatives for
>>> the
>>> commands, but the Java policy ensures that packages are built with the
>>> default JVM, without using any alternatives.
>>>
>>>
>>>>>>> For Ubuntu, it makes it slightly easier if the versionless
>>>>>>> metapackages
>>>>>>> are
>>>>>>> built from a separate -defaults package; this would allow us to make
>>>>>>> separate decisions about making a newer upstream release of golang
>>>>>>> /available/ in a stable release, vs. making it the default.  If you
>>>>>>> are
>>>>>>> concerned about a golang-defaults package being extra overhead,
>>>>>>> though,
>>>>>>> you could also just generate the version-less metapackages from the
>>>>>>> same
>>>>>>> source package as the current upstream version - a small toggle in
>>>>>>> the
>>>>>>> packaging to enable/disable building of these packages would be
>>>>>>> sufficient
>>>>>>> to make that maintainable for both the Debian and Ubuntu use cases.
>>>>>>> (For
>>>>>>> extra cleverness, your packaging could just key on the source
>>>>>>> package's
>>>>>>> name, building them only when the source package is 'golang' and not
>>>>>>> when
>>>>>>> the package is 'golang-X.Y'.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks for providing them -- your pennies are appreciated. :)  This
>>>>>> sounds good to me, and the logic makes sense (and has the benefit of
>>>>>> years of experience behind it).
>>>>>>
>>>>>> I think this new "golang-defaults" package would be a good place to
>>>>>> put a "golang-any" package too (discussed with Paul and Michael
>>>>>> Stapelberg in
>>>>>>
>>>>>> https://github.com/Debian/dh-make-golang/pull/36#issuecomment-172457431).
>>>>>
>>>>>
>>>>>
>>>>> Yeah, that does make sense. So you build-dep on golang-go and get the
>>>>> default version of go, or you build-dep on golang-any and get either
>>>>> golang-go or gccgo depending on arch?
>>>>>
>>>>>> What're our first steps for making all this happen? :)
>>>>>
>>>>>
>>>>>
>>>>> JFDI I guess? I had a stab at making a coinstallable packge at
>>>>>
>>>>>       http://people.canonical.com/~mwh/go-1.6-coinstallability.diff
>>>>>
>>>>> and mostly it's very boring (about half the diff is removing the man
>>>>> pages which would have to move to golang-defaults). The question I
>>>>> guess is how cute one wants to get about making it easy to move from
>>>>> 1.6 to 1.7 or whatever. I had a go at that too:
>>>>>
>>>>>
>>>>> http://people.canonical.com/~mwh/go-1.6-coinstallability-cuter.diff
>>>>>
>>>>> What do you think? I haven't made a golang-defaults package yet but
>>>>> that shouldn't be very hard (will probably involve even more sed
>>>>> though).
>>
>>
>> Thanks for the reviews!
>>
>>>
>>> golang-1.6:
>>>
>>>   - b-d's on gccgo-5 instead of gccgo-6 (will appear in unstable once
>>>     gcc-6 gets into unstable)
>>
>>
>> Done (in
>> https://git.launchpad.net/~mwhudson/ubuntu/+source/golang/+git/xenial/log/?h=ubuntu-xenial-coinstallability-2).
>> I guess we could actually just depend on golang (>= 1.6) now, given
>> that we've got past the icky bootstrapping phase...
>>
>>> golang-defaults:
>>>
>>>   - golang-go needs versioned conflicts with every package providing the
>>>     go symlink, including gccgo-4.9, gccgo-5, gccgo-6, and the old golang
>>>     package. This is to ensure that the alternative is removed, before
>>>     the golang including the symlink is installed.
>>
>>
>> This is the sort of thing I needed advice on. Reading policy isn't
>> Breaks more appropriate than Conflicts? I've added Breaks to the
>> versions of the mentioned gccgo packages currently in Xenial as
>>
>> https://git.launchpad.net/~mwhudson/+git/golang-defaults/commit/?id=f35c9ad8a431ae614b718b991344e2685b2b073d.
>
>
> not sure if a Breaks is sufficient. The goal is to get these packages into
> the uninstalled state. Afaik, the Breaks gets these packages into the
> unconfigured state, with the alternative still present.

I think this is actually OK -- the alternatives is removed by the
gccgo packages' prerm, which is called when they are deconfigured. But
this is obvious hair-splitting, I can change this if you'd rather.

>> We'll need to do a gccgo-6 change at least to stop providing the
>> alternative -- can you handle that or do you want me to make a
>> debdiff?
>
>
> sure, I'll stop providing the alternative with the next upload.

Thanks.

>> What sort of testing can I do of this? I guess installing all the
>> gccgo versions in a container, adding my ppa, and checking they all
>> get removed when I upgrade the golang-go package?
>
>
> yes, that sounds fine.

OK. Once I've done this, are you happy to upload all the packages
referenced in https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1555856
? Or should I bug someone else about that?

Cheers,
mwh

>>> For xenial, we should keep the pseudo golang package depending on gccgo
>>> on
>>> powerpc; for that case you have to adjust the symlinks in the
>>> golang-defaults package.
>>
>>
>> Oh yeah, I totally forgot to add the stuff for different symlinks when
>> depending on gccgo! That's done in git now too.
>>
>> For the record, my plan for golang-go/golang-any goes like this:
>>
>>   * For X, golang-go depends on gccgo on platforms that don't have
>> 'real' golang, as before. The new package golang-any is the same.
>>
>> Then, concurrently:
>>
>>   * Update packages in Ubuntu to depend on golang-any instead of
>> golang-go.
>>   * Get this change into Debian too, but there golang-go will only be
>> built on golang platforms and golang-any will be the one that depends
>> on gccgo or golang-go.
>>
>> Once both of the above done
>>
>>   * merge the change in behaviour of golang-go from Debian and get rid
>> of the last bit of unmergable delta we have
>>
>> Cheers,
>> mwh
>>
>