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
---------- 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
