From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 2B2841389E2 for ; Wed, 17 Dec 2014 22:33:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4423DE0856; Wed, 17 Dec 2014 22:33:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D18E6E0845 for ; Wed, 17 Dec 2014 22:33:28 +0000 (UTC) Received: from big_daddy.dol-sen.ca (S010634bdfa9ecf80.vc.shawcable.net [96.49.31.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dolsen) by smtp.gentoo.org (Postfix) with ESMTPSA id 24A4C3405DF for ; Wed, 17 Dec 2014 22:33:28 +0000 (UTC) Date: Wed, 17 Dec 2014 14:32:55 -0800 From: Brian Dolbec To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] [RFC] Add 'emerge --sync-glsa' action and 'emaint sync-glsa' command Message-ID: <20141217143255.387e52f5.dolsen@gentoo.org> In-Reply-To: <5491E7FD.2080203@gentoo.org> References: <5491E7FD.2080203@gentoo.org> Organization: Gentoo Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 816e730e-a1d1-4806-bc95-ce7af363c5f3 X-Archives-Hash: 3785133f0bd9ac39da38be925748afd9 On Wed, 17 Dec 2014 12:30:53 -0800 Zac Medico wrote: > Hi, > > For server deployments, it's common for administrators to want to use > glsa-check for security vulnerabilities, without necessarily wanting > to to do a full sync [1]. > > So, I propose that we add an 'emerge --sync-glsa' action and a > corresponding 'emaint sync-glsa' command that will only sync the > relevant metadata/glsa subdirectory of the relevant repository(s). > Please respond if you agree or disagree with this proposal. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=89641 I agree in principal, but you didn't say enough about your idea to be able to say yes/no to it yet. I've read the bug comments. So, what you are saying for the above is set a very restrictive rsync to just sync the glsa directory? So, with the new pluging-sync sytem in place, how do you propose we do this? 1) Make a new emaint sync option which does the restriction and appropriate sync module calls? emaint sync --glsa & emerge --sync-glsa 2) emaint sync-glsa sounds like a modified copy of the sync module. To me this is a poor idea. It would needlessly duplicate code. But what about the different sync types. How do we handle this in a git repo instead of an rsync one? 3) if it is a separate repo, then the current emaint sync module does not need __ANY__ modifications. emaint sync -r glsa <== would sync the repo named glsa no matter what type of sync method is used. rsync, git, svn, cvs,... Another advantage to a separate repo, for your use case that they don't want the main repo to be synced, the new sync system adds an "auto-sync" variable. "emerge --sync" will only sync repos marked with it set to yes. So, if all they want is the glsa's synced automatically, set only i'ts auto-sync to yes. All other repos will have to be synced manually via the "emaint sync --repo foo" command which does not look at the auto-sync variable. Bottom line of this comes down to getting infra to create a standalone repo for the glsa's. The current rsync tree could merge the gentoo and glsa repos for backwards compatibility. For your use case, they set the gentoo repo's rsync restriction to exclude the glsa's. And have the separate glsa repo downloaded as it's own repository. With the gentoo tree moving to git, then the git tree would not include the glsa's, so the user would need to install the glsa tree as well. Only code changes I see to portage, pkgcore (I know nothing about paludis) are to look for the glsa's in the 2 possible locations. The standalone glsa repo, failing that, backup to the gentoo tree. -- Brian Dolbec