| 1 | =========================== |
|---|
| 2 | Pkgcore/Portage differences |
|---|
| 3 | =========================== |
|---|
| 4 | |
|---|
| 5 | Disclaimer |
|---|
| 6 | ---------- |
|---|
| 7 | |
|---|
| 8 | Pkgcore moves fairly fast in terms of development- we will strive to keep this doc |
|---|
| 9 | up to date, but it may lag behind the actual code. |
|---|
| 10 | |
|---|
| 11 | -------------------------- |
|---|
| 12 | Ebuild environment changes |
|---|
| 13 | -------------------------- |
|---|
| 14 | |
|---|
| 15 | All changes are either glep33 related, or a tightening of the restrictions on |
|---|
| 16 | the env to block common snafus that localize the ebuilds environment to that |
|---|
| 17 | machine. |
|---|
| 18 | |
|---|
| 19 | - portageq based functions are disabled in the global scope. Reasoning for this |
|---|
| 20 | is that of QA- has_version/best_version **must not** affect the generated |
|---|
| 21 | metadata. As such, portageq calls in the global scope are disabled. |
|---|
| 22 | |
|---|
| 23 | - inherit is disabled in all phases but depend and setup. Folks no longer do |
|---|
| 24 | it, but inherit from within one of the build/install phases is now actively |
|---|
| 25 | blocked. |
|---|
| 26 | |
|---|
| 27 | - The ebuild env is now *effectively* akin to suspending the process, and restarting |
|---|
| 28 | it. Essentially, transitioning between ebuild phases, the ebuild environment |
|---|
| 29 | is snapshotted, cleaned of irrevelent data (bash forced vars for example, or |
|---|
| 30 | vars that pkgcore sets for the local system on each shift into a phase), and |
|---|
| 31 | saved. Portage does this partially (re-execs ebuilds/eclasses, thus stomping |
|---|
| 32 | the env on each phase change), pkgcore does it fully. As such, pkgcore is |
|---|
| 33 | capable of glep33, while portage is not (env fixes are the basis of glep33). |
|---|
| 34 | |
|---|
| 35 | - ebuild.sh now protects itself from basic fiddling. Ebuild generated state |
|---|
| 36 | **must** work as long as the EAPI is the same, regardless of the generating |
|---|
| 37 | portage version, and the portage version that later uses the saved state |
|---|
| 38 | (simple example, generated with portage-2.51, if portage 3 is EAPI compliant |
|---|
| 39 | with that env, it must not allow it's internal bash changes to break the env). |
|---|
| 40 | As such, certain funcs are not modifiable by the ebuild- namely, internal |
|---|
| 41 | portage/pkgcore functionality, hasq/useq for example. Those functions that |
|---|
| 42 | are read-only also are not saved in the ebuild env (they should be supplied |
|---|
| 43 | by the portage/pkgcore instance reloading the env). |
|---|
| 44 | |
|---|
| 45 | - ebuild.sh is daemonized. The upshot of this is that regen is roughly 2x faster |
|---|
| 46 | (careful reuse of ebuild.sh instances rather then forcing bash to spawn |
|---|
| 47 | all over). Additional upshot of this is that their are bidirectional |
|---|
| 48 | communication pipes between ebuild.sh and the python parent- env inspection, |
|---|
| 49 | logging, passing requests up to the python side (has_version/best_version |
|---|
| 50 | for example) are now handled within the existing processes. Design of it |
|---|
| 51 | from the python side is that of an extensible event handler, as such it's |
|---|
| 52 | extremely easy to add new commands in, or special case certain things. |
|---|
| 53 | |
|---|
| 54 | ----------------------- |
|---|
| 55 | Repository Enhancements |
|---|
| 56 | ----------------------- |
|---|
| 57 | |
|---|
| 58 | Pkgcore internally uses a sane/uniform repository abstraction- the benefits |
|---|
| 59 | of this are: |
|---|
| 60 | |
|---|
| 61 | - repository class (which implements the accessing of the on disk/remote tree) |
|---|
| 62 | is pluggable. Remote vdb/portdir is doable, as is having your repository |
|---|
| 63 | tree ran strictly from downloaded metadata (for example), or running from a |
|---|
| 64 | tree stored in a tarball/zip file (mildly crazy, but it's doable). |
|---|
| 65 | |
|---|
| 66 | - seperated repository instances. We've not thrown out overlays (as paludis |
|---|
| 67 | did), but pkgcore doesn't force every new repository to be an overlay of the |
|---|
| 68 | 'master' PORTDIR as portage does. |
|---|
| 69 | |
|---|
| 70 | - optimized repository classes- for the usual vdb and ebuild repository |
|---|
| 71 | (those being on disk backwards compatible with portage 2.x), the number of |
|---|
| 72 | syscalls required was drastically reduced, with ondisk info (what packages |
|---|
| 73 | available per category for example) cached. It is a space vs time trade |
|---|
| 74 | off, but the space trade off is neglible (couple of dict with worst case, |
|---|
| 75 | 66k mappings)- as is, portage's listdir caching consumed a bit more memory |
|---|
| 76 | and was slower, so all in all a gain (mainly it's faster with using |
|---|
| 77 | slightly less memory then portages caching). |
|---|
| 78 | |
|---|
| 79 | - unique package instances yielded from repository. Pkgcore uses a package |
|---|
| 80 | abstraction internally for accessing metadata/version/category, etc- all |
|---|
| 81 | instances returned from repositories are unique immutable instances. |
|---|
| 82 | Gain of it is that if you've got dev-util/diffball-0.7.1 sitting in memory |
|---|
| 83 | already, it will return that instance instead of generating a new one- and |
|---|
| 84 | since metadata is accessed via the instance, you get at most **one** load |
|---|
| 85 | from the cache backend per instance in memory- cache pull only occurs when |
|---|
| 86 | required also. As such, far faster for when doing random package accessing |
|---|
| 87 | and storing of said packages (think repoman, dependency resolution, etc). |
|---|
