From owner-freebsd-pkg@freebsd.org Thu Aug 2 20:21:47 2018 Return-Path: Delivered-To: freebsd-pkg@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7E3E104ED87; Thu, 2 Aug 2018 20:21:46 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EE8D7A63A; Thu, 2 Aug 2018 20:21:46 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-io0-x242.google.com with SMTP id l7-v6so3177451ioj.1; Thu, 02 Aug 2018 13:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7G+P0nqh5TTYT8lhYuusf32FxmpKyw96FJdwW72k3QY=; b=fddmjfThuFcrfjo5zotrx9c8imXc05uZv0ladvAlB5Xi1wbcpyzqlrPXX2fJjF0nIk Z+s0886AeUME9Xlxx4Jn9tV/HAxDG1AWFZejljHNCBIkAG6IsfNjVSzySHO+j7stbuJQ fIG1ckFZK9cmtgLDtDFlSCVlInBeLKNQDCxPTkZB93u25GFnVNcTsWnfkLrRx1Gh/Xz/ E0i+Lt3Pv8uCW4TrrTi71CohwmFDiKLXibdyG0vtUQmy8Cc94V3GREZg7I2A0+eyYjoM aCSdXcGu4ACxNidVX4vlKRmnzSJQLDl8i4hZ9I1SG+s8KP8KiZRpEhRPf2JF1/rQaCk6 oPUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7G+P0nqh5TTYT8lhYuusf32FxmpKyw96FJdwW72k3QY=; b=XcyCrLzLzwOVcIxnlEjdmMW7Ov/cQLAwSpPBkm+uJn1/4pmWvcidugrnVIuan9TXrN Jdt/LI2zD0XWrrWX3pLxxL9oN6hT9o1oiPC9DF3NsqldaUtgyu07IA6qBeP1xFEAtCew AML4sTvYNCybegeCOf+TQ6Q1UkmshA/0E+rgiKpZS/kd5ksro+HRkHeFtvI00d4kFGFp 2shP1dAxiEm2F55Z4Q1Jin46HmVzEWzZU6VHbLFp2x97QmiHqPCL10MdN9yJVzWA+rOh WURw9jOrlKlF/nL/q2D4U5aVTVBi3gLo+7PUE54TULrc95FwTwHwq6Bx7i0HGNYuNbVh RBJw== X-Gm-Message-State: AOUpUlGaBmVf7Dorbl+r08YJqafFRlhlsIMBt500K+5B9OUdTPcTIwq8 OaxfXz+t8YbdeyN7oYMI3Tps16h7GUqqQZ5Glk2J7pf6GKU= X-Google-Smtp-Source: AAOMgpfV5Rzi23Q/LzF3ZtIxkchA74rLqlDwKtGyvL5/ck23UvHVxK+C0LqmWfXZx80to5PcS7dipHClLJ7cn+22SVY= X-Received: by 2002:a6b:c8c8:: with SMTP id y191-v6mr3766056iof.295.1533241305098; Thu, 02 Aug 2018 13:21:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:7781:0:0:0:0:0 with HTTP; Thu, 2 Aug 2018 13:21:04 -0700 (PDT) In-Reply-To: <34cb48da-1f15-1610-966d-1e30314f7665@freebsd.org> References: <34cb48da-1f15-1610-966d-1e30314f7665@freebsd.org> From: grarpamp Date: Thu, 2 Aug 2018 16:21:04 -0400 Message-ID: Subject: Re: Archives of last quarterly package builds? To: freebsd-ports@freebsd.org Cc: freebsd-pkg@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-pkg@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Binary package management and package tools discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 20:21:47 -0000 > I've asked for this but the answer is > "no we don't do that.. and have no plans to". What is the rationale? Or is another model of pkg build, distribution, and archiving coming? It seems no more would be needed than - an update to release / handbook / mirror info noting their status as "final, to be removed [to archives] on date + timeframe", say 1 year. - simple sysadmin on pkg / web side as part of each quarter activity. - some storage space. - obviously they are the final builds of the branch, thus frozen. Anything else / prereqs missing to doing that? In addition to the earlier reasons... 'packages /latest' trails 'repo HEAD' so it's a fairly linear turnover. Yet /quarterly gets a massive bump when the branches swap out from underneath it. So one could also see where enterprise and other pkg users might be expecting a similar progression in /quarterly, and to manually cutforward, not automatic large whack at once. Those production bumps can hurt. So they might choose to track repo_conf /yyyyQn and trial the new quarter before moving to it. It just seems that the final builds on those quarterly branches should be left online for a while, instead of just ...poof...GONE. ie: with pkg, this should work for a year or so... /.../repo_conf: url: "pkg+https://pkg.FreeBSD.org/${ABI}/2018Q2" Some labels could also be added for use in pkg's repo_conf... /last_quarter - simpler than dealing with the date, alternately: /prev_quarter /this_quarter - same as today's /quarterly /head - unlikely due to build / mirror times and other factors /yyyyQn - expose these for manual tracking and cutforward, and the validation purposes below [bcc for thread ref] On Sun, Jul 22, 2018 at 4:44 AM, Julian Elischer wrote: > On 22/7/18 5:59 am, grarpamp wrote: >> >> Packages are delivered via a single quarterly label here >> >> https://pkg.freebsd.org/FreeBSD:11:amd64/quarterly/ >> >> which corresponds to the latest quarterly branch label here >> >> https://svnweb.freebsd.org/ports/branches/?sortby=date#dirlist >> >> >> However, similar to how the tags here >> >> https://svnweb.freebsd.org/ports/tags/?sortby=date#dirlist >> >> are archived here >> >> https://pkg.freebsd.org/FreeBSD:11:amd64/ >> as these >> https://pkg.freebsd.org/FreeBSD:11:amd64/release_[n] >> >> >> The last "ie: final" builds of each quarterly branch before they >> roll over should also be moved off into their own archived >> quarterly directories as > > > I've asked for this but the answer is "no we don't do that.. and have no > plans to". > Which is a putty as it means you need to make your own snapshots if you want > to have any reproducability. > It no linger matters to me as we now roll all our own packages from source > (we have private OS changes > that make this a requirement), but it was a sore point for many years. > > >> >> https://pkg.freebsd.org/FreeBSD:11:amd64/yyyyQ[n] >> >> For example /quarterly/ should be repointed from 2018Q2 >> to 2018Q3, leaving 2018Q2 as a live "pkg" accessible archive. >> >> >> Eventually all such archives could be moved to historical >> archive server under typical release support expiry periods. >> >> >> This would also serve critical purpose as an independant >> original remote repository for validating local package / file >> signatures against compromise, corruption, loss. >> >> >> For example, does the last 2018Q2 (or older ones) still exist >> anywhere for users to reference and use? > > no.