Re: [RFC] Changing priority of selinux back to optional
On Thu, Feb 07, 2008 at 04:34:58AM -0600, Manoj Srivastava wrote:
>..
> Well, don't bother with the SELinux packages; most of them are
> already in Incoming, though I am not packaging straight out of SVN yet.
> I'm sticking to the released versions, until I can see a clear need to
> go to SVN HEAD ...
I had problems with home dir contexts (generating user contexts for
actual mapping system user to SELinux user) with this versions. Must to
say, I didn't to attempt to analyze the problem to much. I went for
newer versions (and some dependency problems too), because I saw, that
Fedora uses these.
E.g. F8 uses:
checkpolicy-2.0.4
libselinux-2.0.43
libsemanage-2.0.12
libsepol-2.0.15
policycoreutils-2.0.33
and maybe these packages are patched a lot.
>...
> Hmm. My packaging does not care, really, what the python
> versions available are; and so on my machine at the moment it provides
> both 2.4 and 2.5 bindings (using python-support). What changes did you
> think needed to be made in the packaging?
This is probably no problem on Sid. Your packaging is ok there.
zito@sid:~$ pyversions -s
python2.4 python2.5
zito@etch:~$ pyversions -s
python2.4
Etch has python2.5, but it is not supported. I must change your
packaging a bit, so this version (python2.5) was used on Etch for
bindings python-semanage.
> Yes, I am still pondering how many packages I need to split this
> into. There are 5 shared libraries, with different so names and
> releases (so could be 2 packages per library -- 10 packages), then
> there are python bindings (can be just one package), there are java
> bindings (another package), and then there are the tools tehmselves,
> adding up to 13 packages.
I did that packages only, so seaudit can run. There is a gap probably.
I did only binaries:
setools
libsefs4
libsefs-dev
libseaudit4
libseaudit-dev
libapol4
libapol-dev
libqpol1
libqpol-dev
libpoldiff1
libpoldiff-dev
libsetools-tcl
You can see at http://linux.i.cz/debian/pool/main/s/setools/
> Well, that makes the packaging effort a non-starter for me; I
> don't want to have to switch into CDBS.
I thought this when I see your worked up system :).
CDBS can reduce packaging code duplication, I think.
> > Openssh package of Sid needs change, because it has problems with
> > initialization of user context. (Not the case for Etch openssh.)
>
> Could you expand on this, please?
http://readlist.com/lists/tycho.nsa.gov/selinux/1/9751.html
Cheers
--
Zito
Reply to: