Summary: | split off common stuff in gnat related eclasses/confs into a separate eclass? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | George Shapovalov (RETIRED) <george> |
Component: | New packages | Assignee: | Gentoo Linux ADA team <ada> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | esigra, mgorny |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 192505 | ||
Bug Blocks: | 137268 |
Description
George Shapovalov (RETIRED)
2007-02-15 10:36:34 UTC
Looks like for implementing proper unmerge cleanup logic I will need to move the unset function form gnat.eselect to common eclass too. So, I'll need to seriously look into doing this. Perhaps most of the eselect functionality will have to be moved to the common eclass and then the eselect module itself would be very simple. George Ok, 90% done. As per discussion with ciaranm in #192505 (why is that when I ask anything on -dev nobody answers? :)) the common code cannot reside in eclass nor anywhere in portage, as eselect module (or, for that matter, any other package not directly dealing with portage tree) cannot depend on portage tree being present. Nor would I accept duplication of code. The solution then is to have the core functions in a separate file belonging to eselect-gnat, (pure bash, no portage or eselect extensions). Everything gnat related depends on eselect-gnat directly or indirectly, therefore it can depend on this file being present at proper time. However it is better not to source that file at top level in any eclass (but this is Ok from within the eselect module). Location of this code: It only makes sence that it would go under /usr/share/gnat, I opted for keeping it inside the lib/ subdir, as this seems to make sense at the moment. Thus it became /usr/share/gnat/lib/gnat-common.bash. I was somewhat hesitant whether this should be under /usr/share or, actually, /usr/lib (which seems to make a bit more sense), but went with the first one, since eselect and all its extra modules put all the scripts under /usr/share. Just need to check what was that comment on the unset function about and then I should be able to close this bug. George Actually this should block that reorg tracker.. |