From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1HlfMy-0006ix-5T for garchives@archives.gentoo.org; Wed, 09 May 2007 06:09:49 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l4968AFB014175; Wed, 9 May 2007 06:08:10 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l496502p009705 for ; Wed, 9 May 2007 06:05:00 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id BBEAE64C03 for ; Wed, 9 May 2007 06:04:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 required=5.5 tests=[HTML_MESSAGE=0.001] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COEQ+ojT2Mxv for ; Wed, 9 May 2007 06:04:57 +0000 (UTC) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by smtp.gentoo.org (Postfix) with ESMTP id C429D64B8F for ; Wed, 9 May 2007 06:04:56 +0000 (UTC) Received: by wr-out-0506.google.com with SMTP id q50so83955wrq for ; Tue, 08 May 2007 23:04:56 -0700 (PDT) Received: by 10.115.47.1 with SMTP id z1mr86626waj.1178690689542; Tue, 08 May 2007 23:04:49 -0700 (PDT) Received: by 10.114.126.16 with HTTP; Tue, 8 May 2007 23:04:44 -0700 (PDT) Message-ID: Date: Tue, 8 May 2007 23:04:44 -0700 From: "Alec Warner" Sender: antarus@scriptkitty.com To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] [RFC - Moving categories around] In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_84497_31449933.1178690684481" References: X-Google-Sender-Auth: 69552b981e0baa5b X-Archives-Salt: 417965ec-b3a2-4b73-8885-52d35f9cd911 X-Archives-Hash: c9fe6ac905407e9039f6a88dccf8f058 ------=_Part_84497_31449933.1178690684481 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline oops, sent with wrong address the first time. ---------- Forwarded message ---------- From: Alec Warner Date: May 8, 2007 9:09 PM Subject: [RFC - Moving categories around] To: gentoo-dev@gentoo.org So a random thought I had was 'lets move categories out of gentoo-x86/ and into gentoo-x86/ebuilds/' The existing layout is: gentoo-x86/ - // - // ..... - // - profiles/ - scripts/ - metadata/ - eclass/ - distfiles/ - local/* - licenses/* The new layout would be: gentoo-x86/ - profiles/ - scripts/ - metadata/ - eclass/ - licenses/ - ebuilds///...and so forth - local/* - distfiles/* (* indicates a common directory for rsync users). The benefits include making the layout cleaner, obsoleting the categories file. The risks primarily include breaking a bunch of crappy old tools, as well as all existing package managers and user installations for those users who have not upgraded. I would personally fix portage and anything in gentoolkit and gentoolkit-dev. This change would involve breaking all old installations of gentoo that still sync the tree for updates such as GLSA's but don't upgrade their package manager to a version that supports the new ebuild locations. I don't really know how we support those users at present. An upgrade path would need to be provided, particularly the user must be able to use an older version of a package manager in conjunction with an ebuild to upgrade itself to a version that supports the new tree format. This seems to me that we should come up with a tree format scheme such that when updating the tree, the package manager can then detect if it supports the updated tree's format or not. The upgrade case is then solved by the package manager refusing to fetch tree updates until the user upgrades the package manager to a version that supports the new tree format. The corner case here is where someone bumps the tree version but all available package managers are not yet in the tree. This would prevent users from upgrading to a version of their package manager that supports the new tree format because the ebuilds would no longer be available in the old format. An interesting solution to this would be to split the rsync data in to 2 trees, one 'old format tree' and one 'new format tree' and users can configure their clients appropriately. eventually the old format tree would be deprecated; tree changes would be replicated to both trees. Flame on -alec ------=_Part_84497_31449933.1178690684481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline oops, sent with wrong address the first time.

---------- Forwarded message ----------
From: Alec Warner <antarus@scriptkitty.com >
Date: May 8, 2007 9:09 PM
Subject: [RFC - Moving categories around]
To: gentoo-dev@gentoo.org

So a random thought I had was 'lets move categories out of gentoo-x86/ and into gentoo-x86/ebuilds/'

The existing layout is:

gentoo-x86/
 - <category1>/<pn...>/<ebuilds + misc stuff>
 - <category2>/<pn...>/<ebuilds + misc stuff>
.....
 - <categoryN>/<pn...>/<ebuilds + misc stuff>
 - profiles/
 - scripts/
 - metadata/
 - eclass/
 - distfiles/
 - local/*
 - licenses/*

The new layout would be:
gentoo-x86/
  - profiles/
  - scripts/
  - metadata/
  - eclass/
  - licenses/
  - ebuilds/<category...>/<pn...>/...and so forth
  - local/*
  - distfiles/*

(* indicates a common directory for rsync users).

The benefits include making the layout cleaner, obsoleting the categories file.

The risks primarily include breaking a bunch of crappy old tools, as well as all existing package managers and user installations for those users who have not upgraded.

I would personally fix portage and anything in gentoolkit and gentoolkit-dev.

This change would involve breaking all old installations of gentoo that still sync the tree for updates such as GLSA's but don't upgrade their package manager to a version that supports the new ebuild locations.  I don't really know how we support those users at present.

An upgrade path would need to be provided, particularly the user must be able to use an older version of a package manager in conjunction with an ebuild to upgrade itself to a version that supports the new tree format.

This seems to me that we should come up with a tree format scheme such that when updating the tree, the package manager can then detect if it supports the updated tree's format or not.  The upgrade case is then solved by the package manager refusing to fetch tree updates until the user upgrades the package manager to a version that supports the new tree format.  The corner case here is where someone bumps the tree version but all available package managers are not yet in the tree.  This would prevent users from upgrading to a version of their package manager that supports the new tree format because the ebuilds would no longer be available in the old format.

An interesting solution to this would be to split the rsync data in to 2 trees, one 'old format tree' and one 'new format tree' and users can configure their clients appropriately.  eventually the old format tree would be deprecated; tree changes would be replicated to both trees.

Flame on

-alec
 ------=_Part_84497_31449933.1178690684481-- -- gentoo-dev@gentoo.org mailing list