From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Q69Yp-00043s-6q for garchives@archives.gentoo.org; Sat, 02 Apr 2011 22:44:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5CD17E04C1; Sat, 2 Apr 2011 22:44:30 +0000 (UTC) Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 1E1E1E04C1 for ; Sat, 2 Apr 2011 22:44:29 +0000 (UTC) Received: by vws13 with SMTP id 13so4265396vws.40 for ; Sat, 02 Apr 2011 15:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=XnFdMvh+/N6YAghd3LNCCT5Q20fTMZWrZSpA8ROSFbk=; b=FsPiVvx4bK7qk5qKFwJq9s+uHhiCfVunIE7dR/pjrC3I3JzV3oH4EhflrJ2AflfyX0 wLy31xuQ0T4QhJ17TGLqis1hpdzaWR5mNdRQSOCO5r/Evke5DMWOKSG/XjhIkazf6kXe UkFBcFvwSpWShrD7Bf/2P/oqAYZSzQ2oFoRS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=Jq1b2AYVV9N/yzeHD4CTBQtBRLEpJaiS07Yhf9otqiVkcKIRTyaW/IU8Kd5yktHxjw Soa3HzqSZsr1aUwusHMfgHjBASJrR/QfAysAEjGSJzyZSiDAwHWiMBCZEdGBg3zKpf3D 9CDyI9fV1vuAavtadtT4kbR0kbQIr5cyvJst4= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org MIME-Version: 1.0 Received: by 10.52.88.48 with SMTP id bd16mr1824628vdb.231.1301784269531; Sat, 02 Apr 2011 15:44:29 -0700 (PDT) Sender: cjosephsonful@gmail.com Received: by 10.52.168.134 with HTTP; Sat, 2 Apr 2011 15:44:29 -0700 (PDT) Date: Sat, 2 Apr 2011 17:44:29 -0500 X-Google-Sender-Auth: TYdcHpT6iTph1TCR_mLuz19Qzig Message-ID: Subject: [gentoo-soc] SCM Snapshot management From: Colleen Josephson To: gentoo-soc@lists.gentoo.org Content-Type: multipart/alternative; boundary=20cf307f381af5ab40049ff7442f X-Archives-Salt: X-Archives-Hash: dbcd36a10e1f81fec7abf1cbe3748e87 --20cf307f381af5ab40049ff7442f Content-Type: text/plain; charset=ISO-8859-1 The SCM snapshot management project ( http://www.gentoo.org/proj/en/userrel/soc/ideas.xml#doc_chap2_sect18), paired with adding tags to Portage, search improvements, and a couple other small Portage feature additions. To quote Luca Barbato: The idea is to work on the concept so that: - by emerging a live ebuild you automatically generate the snapshot ebuild and record it...instead of recording it as live ebuild in the vdb you record it as snapshot ebuild. The generation step could include a version generation algorithm more complicated than you expect - you have a emaint command to generate the snapshot ebuild on the fly. Where exactly would the information of a live vs. snapshot ebuild be recorded in the vdb? I checked out my own VDB, and it had some text files like: BUILD_TIME CBUILD CHOST COUNTER DEFINED_PHASES DESCRIPTION FEATURES INHERITED KEYWORDS LICENSE NEEDED.ELF.2 RDEPEND SLOT environment.bz2 repository CATEGORY CFLAGS CONTENTS CXXFLAGS DEPEND EAPI HOMEPAGE IUSE LDFLAGS NEEDED PF SIZE USE jack-audio-connection-kit-0.120.1.ebuild I checked the contents of most of them, but none seemed like particularly likely locations to store that information. Also, the project description says: - If the writer has no access (the ebuild is not uploaded to main tree or a listed overlay), the ebuild behaves as a live ebuild. - Otherwise, the snapshot manager daemon packages the snapshot and posts it on Gentoo mirrors. The ebuild fetches the snapshot and uses it. (this will require a manifest update upon/after commit...) So I think that means that if the ebuild writer is a dev, the snapshot will be posted to Gentoo mirrors. If not, the ebuild is not snapshot and is a live ebuild. I think it would be nice to have the ability to use locally-stored snapshots instead of forcing those who are not devs to do live ebuilds. I was thinking for the versioning, perhaps something revision numbers would be sensible? Thanks, -Colleen --20cf307f381af5ab40049ff7442f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The SCM snapshot management project (http://www.gentoo.org/proj/en/us= errel/soc/ideas.xml#doc_chap2_sect18), paired with adding tags to Porta= ge, search improvements, and a couple other small Portage feature additions= .

To quote Luca Barbato:
The idea is to work on the concept so that:
- by emerging a live ebuild you automatically generate the snapshot
ebuild and record it...instead of recording it as live ebuild in the vdb yo= u record
it as snapshot ebuild. The generation step could include a version
generation algorithm more complicated than you expect

- you have a emaint command to generate the snapshot ebuild on the fly.

Where exactly would the information of a live vs. snapshot ebuild be re= corded in the vdb? I checked out my own VDB,
and it had some text files= like:
BUILD_TIME=A0 CBUILD=A0 CHOST COUNTER=A0 DEFINED_PHASES=A0 DESCRI= PTION=A0 FEATURES=A0 INHERITED=A0 KEYWORDS=A0 LICENSE=A0 NEEDED.ELF.2=A0 RD= EPEND=A0 SLOT environment.bz2 repository CATEGORY CFLAGS=A0 CONTENTS=A0 CXX= FLAGS=A0 DEPEND=A0 EAPI=A0 HOMEPAGE=A0 IUSE LDFLAGS=A0 NEEDED=A0=A0 PF=A0 S= IZE=A0 USE jack-audio-connection-kit-0.120.1.ebuild

I checked the contents of most of them, but none seemed like particular= ly likely locations to store that information.

Also, the project des= cription says:
  • If the writer has no access (the ebuild is not = uploaded to main tree or a listed overlay), the ebuild behaves as a live eb= uild.
  • Otherwise, the snapshot manager daemon packages the snapshot=20 and posts it on Gentoo mirrors. The ebuild fetches the snapshot and uses it. (this will require a manifest update upon/after commit...)
So I think that means that if the ebuild writer is a dev, the sna= pshot will be posted to Gentoo mirrors. If not, the ebuild is not snapshot = and is a live ebuild.
I think it would be nice to have the ability to us= e locally-stored snapshots instead of forcing those who are not devs to do = live ebuilds.

I was thinking for the versioning, perhaps something revision numbers w= ould be sensible?

Thanks,
-Colleen
--20cf307f381af5ab40049ff7442f--