Re: [Tarantool-patches] [PATCH v5] gitlab-ci: implement packing into MCS S3

[Alexander Turenko <alexander.turenko@tarantool.org>]

Igor, thanks a huge for the deep investigation of approaches around
other software!

Updates:

* We agreed on names 'live' (instead of 'nightly') and 'release'.
* We agreed to don't include major and minor version into package names.
* We agreed to split repos to 1.10/2.1/2.2 and so.
* We agreed on replacing current packagecloud repos with the new ones,
  because the end result looks quite similar (except that the new repos
  will be never pruned).
* We agreed to provide more recipes like 'how to update from a release
  version to one with necessary bugfix', 'how to move from this live
  version to the next release when it will be published'.
* We consider extracting modules and connectors into a separate
  repository, starting from 2.4 or 2.5.
* We consider providing tarantool-110-release and tarantool-110-live
  packages, which will install and enable corresponding repositories.
* We consider providing some tooling to manipulate tarantool
  repositories, a kind of `eselect` in Gentoo.
* We consider providing a user recipes how to stick with certain
  tarantool version or version range.

Reasoning behind those agreements is below four dashes.

'We agreed' basically means that me and Igor agreed that a proposed way
have more pros (or less cons) that an alternative, at least on typical
operations around a package.

'We consider' means that we discussed a proposal and it looks promising,
but there is no strict understanding how it should be implemented and
there is no issue tracking this task.

The discussion is open and we'll appreciate substantiated opinions: cons
and pros in light of a certain use case, examples of good and bad
experience with other software repositories, rules of thumb we didn't
notice.

----

We build packages for every push, but not on a schedule, so name
'nightly' is inaccurate. 'live package' is the term from (at least)
Gentoo that means a package that always installs a last version from a
version control system. This is very similar to what our repos offer.

We looked at PostgreSQL, MySQL and MongoDB repositories and found that
only PostgreSQL packages have major and minor version as a part of a
package name. But they can be installed simultaneously into different,
collision-free paths on a system. A user may expect that packages with
different names may be installed in parallel.

Different package names suggest a package manager that those packages
are different, but conflicting ('Provides' the same on CentOS / Fedora,
conflicts by paths on all distros). So it is not possible to update
from, say, tarantool110 to tarantool224: one need to remove tarantool110
and then install tarantool224. This leads to removing all packages that
depends on tarantool (at least on CentOS / Fedora), which unlikely what
a user expects.

Since we going to provide packages w/o a version in a name we should
give a user a stable version by default (say, last 2.2, not last 2.4).
This is usually achieved using separate repositories. For us it seems
natural to continue using <major>.<minor> names for them. (So, quick
installation guide will show a user how to enable 2.2 repository, while
more in-depth part can reveal another possibilities.) It is more
straightforward and flexible than stable/unstable/bleeding_edge
repositories.

Re stick with a version / a version range: see the following links.

* https://access.redhat.com/solutions/98873
* https://unix.stackexchange.com/a/162785/58434

WBR, Alexander Turenko.

On Sun, Jan 19, 2020 at 02:26:27AM +0300, Igor Munkin wrote:
> Sasha,
> 
> Thanks for the discussion results you provided! Some light can be seen
> at the end of the tunnel.
>
> <...>
>
> -- 
> Best regards,
> IM