Summary: | update portage for python-selinux / libselinux swig wrapper collision | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Chris PeBenito (RETIRED) <pebenito> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | major | Keywords: | InVCS |
Priority: | Highest | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 115839 | ||
Attachments: |
portage.py-selinux_aux-rename.diff
backwards-compatible patch selinux_aux rename try 2 new portage_selinux compatibility module new portage_selinux compatibility module new portage_selinux compatibility module |
Description
Chris PeBenito (RETIRED)
2006-02-11 18:32:52 UTC
Created attachment 79548 [details, diff]
portage.py-selinux_aux-rename.diff
This is made against the portage.py in 2.1_pre4-r1.
Created attachment 79593 [details, diff]
backwards-compatible patch
How about this (untested) patch instead? This makes portage try to import the renamed selinux_aux first and falls back to selinux if it cannot be imported. I'm afraid of circular dependencies with the other patch (if you install the renamed bindings before the patched portage.py or the patched portage.py before renaming the bindings selinux support stops working).
no, we can't do that. Like I said, not all of the functions of selinux_aux exist in the swig wrapper. And in the long run I want to switch over to the functions that are in the swig wrapper (same libselinux function, but they have different names in the wrapper and different returns). also, right now the only available python-selinux has both selinux_aux.so and selinux.so. Hopefully by the time the portage that has this update goes stable, hopefully most selinux users will already have the right python-selinux. And with the right dep set, it should pull in the right python-selinux anyway. I think we're misunderstanding each other here. Here's what I think the situation is: Older versions of python-selinux install selinux.so. Newer versions install selinux_aux.py (which provides the same functions selinux.so does, and depends on selinux.py from newer versions of libselinux to do so). If you "import selinux" when such a new python-selinux is installed you get libselinux's selinux.py which does not provide everything selinux.so did. Correct so far? With your patch applied portage will *only* work correctly with the new version of python-selinux installed (it only tries to import selinux_aux). However, portage without your patch will *only* work correctly with the old selinux installed (it only tries to import selinux). This is a problem: if you make portage depend on the newer python-selinux like you suggest there's nothing stopping people from upgrading to the new python-selinux first, then trying to upgrade portage in a new emerge run, which will not work since the old portage does not grok the new python-selinux. With my patch applied portage should work correctly with both the new and the old python-selinux: if the new one is there it will import and use selinux_aux, ignoring the selinux module. If the new selinux_aux is not there it will import selinux instead. Then python-selinux could depend on a portage version with that patch applied and the upgrade would be "safer": you can upgrade portage first (and the new portage will work with the old python-selinux just like the old one did) and then upgrade python-selinux (and it will start using selinux_aux). Please tell me what I'm missing :) Well I realized there is an even safer upgrade path. The libselinux swig wrapper (selinux.py) looks like this: import _selinux is_selinux_enabled = _selinux.is_selinux_enabled is_selinux_mls_enabled = _selinux.is_selinux_mls_enabled getcon = _selinux.getcon . . . and creates all of these aliases for all of the library wrapper functions in _selinux.so. I can just add aliases in selinux.py to the functions to selinux_aux. Then there will be a nice compatability layer, and portage can switch over to the right functions in one shot, and not worry about compatability. I'll make a new patch. Created attachment 80803 [details, diff]
selinux_aux rename try 2
how about this patch. With this new setup, the python-selinux dependency should be >=dev-python/python-selinux-2.16-r2 instead of -r1 as I stated above.
*nudge* we really need to get this in stable and dev branches of portage. ok, this has been sitting long enough that it doesn't apply anymore to the dev branch, I guess I'll have to rebase it :| The multiple libraries thing is a little messy and I think it would nice to isolate them inside a new module called portage_selinux. I don't agree with it being messy, but I'm not sure what you mean by isolate them in a new module. Make a dummy portage_selinux.py that just imports the two modules? actually, since selinux_aux functions are just helper functions that eventually just call stuff in libselinux, a better option might be to just make a portage_selinux.py in portage itself, then only the selinux module would have to be imported. http://cvs.sourceforge.net/viewcvs.py/python-selinux/python-selinux/selinux_aux.prx?rev=1.1&view=auto Not all of that would be added, just the secure_* functions. (In reply to comment #11) > Make a dummy portage_selinux.py that just imports the > two modules? Yes, because I'd rather not spread third party apis throughout the internals of portage. If we wrap the third party apis in a portage_selinux module, the dependency on those apis will be isolated (rather than dispersed throught the portage internals). Created attachment 87430 [details, diff]
new portage_selinux compatibility module
This patch applies against 2.1_rc2-r2 and current svn. If this patch works then I'll go ahead and put it in, so please test.
Created attachment 87431 [details, diff]
new portage_selinux compatibility module
Fixed accidental attempt to import getcon from selinux_aux.
Created attachment 87433 [details, diff]
new portage_selinux compatibility module
Fixed is_selinux_enabled() == 1 logic. Sorry for the extra spam. :/
This is fixed in svn r3430. This has been released in 2.1_rc3. |