From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 4598646970E for ; Wed, 22 Jan 2020 04:35:38 +0300 (MSK) Date: Wed, 22 Jan 2020 04:35:44 +0300 From: Alexander Turenko Message-ID: <20200122013543.2jd7trabto3zokcf@tkn_work_nb> References: <20200114174229.vnf6ubpgw265arsb@tkn_work_nb> <20200118232627.GO31304@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200118232627.GO31304@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v5] gitlab-ci: implement packing into MCS S3 List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Munkin Cc: Yaroslav Dynnikov , tarantool-patches@dev.tarantool.org, Konstantin Nazarov 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 . 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