diff options
author | 2010-09-19 20:36:04 +0000 | |
---|---|---|
committer | 2010-09-19 20:36:04 +0000 | |
commit | 8d5cf8ffbb8d295cfdd7be1e684b0d7cfb4f6b13 (patch) | |
tree | 30c76a1b5ee9afb5e1c7e6b6f7a429fb92eec9fb /users | |
parent | initial import of per-package eclass glep (diff) | |
download | gentoo-8d5cf8ffbb8d295cfdd7be1e684b0d7cfb4f6b13.tar.gz gentoo-8d5cf8ffbb8d295cfdd7be1e684b0d7cfb4f6b13.tar.bz2 gentoo-8d5cf8ffbb8d295cfdd7be1e684b0d7cfb4f6b13.zip |
Add feedback
Diffstat (limited to 'users')
-rw-r--r-- | users/antarus/projects/gleps/glep-XX.txt | 28 |
1 files changed, 26 insertions, 2 deletions
diff --git a/users/antarus/projects/gleps/glep-XX.txt b/users/antarus/projects/gleps/glep-XX.txt index c9a1810961..61bdd6ffe5 100644 --- a/users/antarus/projects/gleps/glep-XX.txt +++ b/users/antarus/projects/gleps/glep-XX.txt @@ -13,8 +13,7 @@ Abstract ======== This document proposes a new kind of eclasses, which are specific to a certain -package (hence "per-package eclasses"). It explains the current need for -package specific eclasses, the proposed solution and a possible migration path. +package (hence "per-package eclasses"). What is proposed is, in short, creation of eclasses in package directories for use by the ebuilds of the package in the same directory. Per-package eclasses @@ -39,6 +38,21 @@ clutter in the current eclass directory, provide a single directory to understand an ebuild and provides security benefits by including the eclasses in the Manifest file. +<!-- ANTARUS +Editors Note +The document fails to explain how these problems will be solved. For +instance, how will per-package eclasses reduce the total number of eclasses in +/eclass? The data show that the number of eclasses will be reduced by +three (mysql, php, and nvidia-drivers.) This is not a compelling argument. + +How do per-package eclasses make overlay usage easier? If a user is working +on a package and the package has a per-package eclass in tree already, how is +that any different from the current situation (over-riding an eclass in +/eclass vs over-riding a per-package eclass.) The only gain seems to be in +limiting eclass scope. Editing a per-package eclass means only one package is +affected. +--> + Specification ============= @@ -78,6 +92,16 @@ regenerating Manifests in a specific package directory. It is assumed that whoever changes functionality in a package also uses tools capable of supporting features used in the package's ebuilds. +<!-- ANTARUS +Editor Note: +What happens when an old version of portage encounters a manifest entry it +does not recognize? How will these manifests be generated? What kind of +entries? What kind of checksums? The GLEP omits all of this information. + +How long will it take to implement these manifest tools? How long must +clients wait if PMs die on unknown manifest types? +--> + Copyright ========= |