From: nicolas.iooss@m4x.org (Nicolas Iooss) Date: Thu, 9 Feb 2017 10:48:39 +0100 Subject: [refpolicy] policy releases In-Reply-To: <20170209021625.GA6479@meriadoc.perfinion.com> References: <1716668.X9W763Kd3L@russell.coker.com.au> <59007870-6ef9-1d3d-d12e-6921e59a8ebd@ieee.org> <47972742.QHH7Tdg2Tm@russell.coker.com.au> <20170209021625.GA6479@meriadoc.perfinion.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Thu, Feb 9, 2017 at 3:16 AM, Jason Zaman via refpolicy < refpolicy@oss.tresys.com> wrote: > On Thu, Feb 09, 2017 at 12:27:53PM +1100, Russell Coker via refpolicy > wrote: > > On Wednesday, 8 February 2017 4:40:17 PM AEDT Chris PeBenito wrote: > > > On 02/07/17 22:09, Russell Coker via refpolicy wrote: > > > > Could we have a shorter delay between official releases of refpolicy > than > > > > normal for this cycle? > > > > > > I'm open to something sooner, to a point; perhaps a month. I'd like to > > > make sure everyone, especially distros, have sufficient time to try out > > > the usrmerge stuff. > > > > Are the other distro maintainers trying out the git changes? > > > > I usually don't test git code, I only test it when it is part of a > release. > > I'll only test git code if there is a significant amount of time and > patches > > elapsed since the last release (like a year). If you are hoping that I > will > > test patches you accept from other people then it's not going to work > out. > > Yep. So let me explain gentoo's workflow a bit. It's a little different > cuz gentoo is rolling and not release based so waiting for refpolicy > releases doesnt really work. > > I only use gentoo's hardened-refpolicy (official repo is here: > https://gitweb.gentoo.org/proj/hardened-refpolicy.git/ i mirror to my > github too). Our release script (gentoo/release-prepare.sh) makes a big > patchfile on top of the latest refpolicy release then our ebuilds > extract refpol and apply the patch on top. > Our releases are -r. > > eg currently for sec-policy/selinux-base: > Available versions: 2.20151208-r4 2.20151208-r6 2.20161023-r1 > 2.20161023-r3 (~)2.20161023-r4 (**)9999 > The 9999 version will pull the latest git HEAD and its what swift and I > mostly use during dev. > > Before each release we pull in any changes from the refpol upstream repo > and merge them into the gentoo one. For gentoo-specific things i'll > apply them to our repo (almost always inside an ifdef distro_gentoo > block). Otherwise I generally prefer to submit the patches upstream > first then pull back down. I'll skip upstream if its a policy that we > havent upstreamed yet or if something is super broken and I need to make > a release right away. (or if im lazy ...) > > Mainly its cuz things are rolling, i'll only see that something is > broken when it gets installed on my or someones system and they file a > bug. so if eg apache had a problem and it just got stabilized i cant > wait months for the next refpol release because people are using it. > > That said, more frequent releases is definitely not a bad thing at all, > it just isnt as vital for my workflow as others. I *think* nicolas has a > similar patchset on top of the git repo for Arch but not sure exactly. > Actually there is no official policy for Arch Linux (I tried to maintain one 1 or 2 years ago but I could not do this on my own) and I do not know what users are using. I am mainly packaging the programs and libraries and the free time I have recently spent on SELinux-related projects has been taken by extensively testing the tools. On my systems, I am using refpolicy's git master branch with about 100 patches (some for systemd support, one to convert /usr/sbin to /usr/s?bin, some for custom policies for the programs I use, etc.). This way I am kind of testing the git changes before they are released. When refpolicy will fully support recent systemd systems, it will make sense to create a policy package for Arch Linux to ease its installation and I will also be interested in more frequent releases, to minimize the differences between the release and git master. It won't be as integrated with the package manager as in Gentoo, but it will hopefully provide a good base for Arch Linux users. Cheers, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20170209/00b6247d/attachment.html