From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6542418157487783936 X-Received: by 2002:a24:4c6:: with SMTP id 189-v6mr488743itb.34.1523542359051; Thu, 12 Apr 2018 07:12:39 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.107.90.8 with SMTP id o8ls777583iob.24.gmail; Thu, 12 Apr 2018 07:12:38 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/WDt5GvP1LKpu/GvI4TlJLkA9u6P0qgiLEGjNpe75aJSoB33kOO+Oud0AyV8V7p0gT2z3T X-Received: by 10.107.105.9 with SMTP id e9mr4247241ioc.87.1523542358559; Thu, 12 Apr 2018 07:12:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523542358; cv=none; d=google.com; s=arc-20160816; b=aJ0JRA/D5sVOw8ksbXJ5hYvOwapXxXiJY2pT70EUVpGLaJZUMocfzHhX+FkKDHZLed 9mHdgceiZwwpjG4rXukUzMjq5DB5gBWl8ZyiIZ6ZMsqKfoMBNVs6hp/+lCX8+GD/BgJN bDIxQRfubchuo1KgX0ntcq14uNEsf11kix1UJ82dJjiUCD3v8f2Khwh3mOOunQznPv6e O5hIPPove85Vm/Tpoh8kNBg/iByhTbEo9pJ+WxGvRx3CkwbaQAtT7nJmp4hU1wfV0Mql xB1PS95p5cWvYKrNjWiQsH/tEPWwOBw0HyHLfDFIYptLX7XU8N7hY+bQVO4+H/ijcBqP jzOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date :arc-authentication-results; bh=qYNOsZ6tb4Q8/A3aN/YThCsNiXluAOhs8Z1LF4y/zag=; b=KNEtoAWng74w2lzozuj/iGE3cB2H2cltqDmulTx5Iunhy++rLOC2XC8vOT9NnhhhA7 XJCyjeBgqtoSbtjTapKSja40f1su9F+X/xvNhn9juDRXDS+gxk1RS6Jwtt2e2G3G/krw 0uLaXvLvdIKGY/036/R21hZspqQgQmJcMxYbSggUSFmbq9LW3w0qNt+MO00g1uECHuz/ wdr7IzBZA+iy75pEgWyU2WMwZnhirf19QT1rlE9wIai7X828nF6757OTG4VswueVSXjT fE8MXkgJ/ShMubqZbSnFvTwSJ7SSh43/hGd9umrzJdEwuGxmpDD3gWksAr3F+5DpXesF qiNw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from aqmola.ilbers.de (aqmola.ilbers.de. [85.214.62.211]) by gmr-mx.google.com with ESMTPS id r2si306000ioc.0.2018.04.12.07.12.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Apr 2018 07:12:38 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.62.211; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.62.211 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.radix50.net (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by aqmola.ilbers.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id w3CECY5f004518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Apr 2018 16:12:35 +0200 Received: from yssyq.radix50.net (localhost [127.0.0.1]) by yssyq.radix50.net (8.14.4/8.14.4/Debian-8) with ESMTP id w3CECXgm015868 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Apr 2018 16:12:33 +0200 Received: (from ibr@localhost) by yssyq.radix50.net (8.14.4/8.14.4/Submit) id w3CECXJF015867 for isar-users@googlegroups.com; Thu, 12 Apr 2018 16:12:33 +0200 Date: Thu, 12 Apr 2018 16:12:33 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [DISCUSSION] Mirror implementation with isar-bootstrap Message-ID: <20180412141233.GD6864@yssyq.radix50.net> Mail-Followup-To: isar-users@googlegroups.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-TUID: 9jg0o5SQBSlK Hello Claudius, On Mon, Apr 09, 2018 at 02:03:49PM +0200, Claudius Heine wrote: > AFAIK apt doesn't has a native support for mirror selection that could be > simply adapted to our use-case. Debian itself uses http redirection to find > the closest remote server (http://httpredir.debian.org/) Which we used to have in Isar master and which failed sporadically with some 4xx errors, so we've reverted to f.d.o. > What we want is being able to overwrite official mirror URIs with our own. > OEs mechanism to deal with this is the PREMIRRORS variable [1]. > It basically contains a regex and a replace string separated by a whitespace > where each of those sets is separated by a new line. > > We could do something similar like this: > > PREMIRRORS="http://ftp.debian.org/ http://internal.mirror/ \n > ..." I usually prefer to define vars in local.conf and sed 's/##DEBIANMIRROR##/$DEBIANMIRROR/' debian-stretch.list.in > debian-stretch.list, so that the user can see what is being used. Patching on the fly is too magic for me :) . That said, since upstream does it in that way and people are familiar with it, I'm fine with it. > If this is not the case, then things are getting more difficult. > My first question is: Can we assume the internal mirrors are 1:1 copies of > the external ones? I think projects would usually be able to satisfy whatever Isar expects. I'd assume that an internal mirror to use has all files that are needed for an Isar-based project. (Depending on what you mean by "1:1": It has to contain all files needed, not all available in Debian, and possibly in other paths, not necessarily where f.d.o has them -- that is handled by Packages.gz). > If not then here are some other solutions: > > PREMIRRORS="http://ftp.debian.org/ stretch http://internal.mirror/ \n > ..." > > This way we could select additionally the distribution suite. It's just a > bit more flexible but maybe not enough? We could add components and what not > here as well. Maybe we also need to split between 'deb' and 'deb-src' > mirrors? If this is needed at this time, my suggestion would be matching the whole sources.list line or even the file as you suggest below. That said, I'd be reluctant to do that if that would break the upstream PREMIRRORS syntax as people know it. > With those previous examples PREMIRRORS are operating on the global > aggregated source list. So maybe specifying which file they needed to be > applied could be better: > > PREMIRRORS="conf/distro/stretch.list http://ftp.debian.org > http://internal.mirror \n > ..." > > That might limit the effect of those regexes to lower the risk of > accidentally overwriting anything else. > > I currently don't know how flexible we need to design this, so that is why I > am asking the community. If this is not needed at this time, I'd suggest that we look at your initial implementation and keep it simple, stupid till it becomes necessary. Then we would have the exact requirements. With kind regards, Baurzhan.