[Buildroot] [PATCH 00/29] SELinux Buildroot Additions

[Matthew Weber]

Dear Thomas,

On Mon, Jan 5, 2015 at 9:15 PM, Matthew Weber
<matthew.weber at rockwellcollins.com> wrote:
> Dear Thomas,
>
> On Fri, Jan 2, 2015 at 2:59 PM, Matthew Weber
> <matthew.weber at rockwellcollins.com> wrote:
>> Thomas,
>>
>> On Jan 1, 2015 3:47 PM, "Thomas Petazzoni"
>> <thomas.petazzoni at free-electrons.com> wrote:
>>>
>>> Dear Matt Weber,
>>>
>>> On Mon, 15 Dec 2014 21:53:52 -0600, Matt Weber wrote:
>>>
>>> > ### What's in this patchset?
>>> >
>>> > This patchset adds the required userspace tools, libraries, example
>>> > QEMU target, existing package modifications, and initial policy
>>> > to Buildroot.
>>>
> <snip>
>>>
>>> Finally, I have found what appears to be the new Git repository for the
>>> SELinux development at https://github.com/SELinuxProject/selinux. And
>>> it seems that now all components are in a single Git repository. Are
>>> they still doing separate tarballs for each component? I have the
>>> feeling that packaging separately checkpolicy, libselinux, libsemanage,
>>> libsepol, policycoreutils and sepolgen is maybe not the way to go.
>>>
>>> Can you clarify this before I spend more time merging more of your
>>> patches?
>>
>> Definitely.  In general we errored on the side of using older stable libs
>> when we pulled our selinux config together.  (Didn't realize the possible
>> change in how the libs/tools were organized) I'll take a look at pulling
>> things to the latest and see how that impacts how those packages are built.
>> I know that there were cross compile issues with a couple of the packages
>> that we worked around so I'll see how things look porting wise.
>>
>> Thank you for the review and pulling this in.  I'll spend some time Monday
>> figuring out if we should merge these patches or update to match the new
>> repo layout.
>>
>
> It looks like they have set things up to support backwards
> compatibility with separate releases for the different packages,
> however I'd rather refactor the patchset to use the new approach.

I just noticed that the release script they use is intentionally
packaging each folder/package separately, so it does look like that's
their current approach (even in a single repo).  I think we still
should consolidate it into a single package.  For every disadvantage I
can think of for having it as one package, I can see resolving those
through a temporary patch or the way the Kconfig exposes what's built.

> This would allow us to closely track the development and make it much
> easier to update as things would be a single package with a single
> version to bump.  I did notice that since they converted it from an
> autotools based build to static Makefiles, it looks like we may have
> lost some of the capability to turn off features.  So I guess worst
> case we also would have some patching needed to add back in that
> capability.
>
> I'll can get started on rev2 of the patchset using the single package
> approach. Would it work to revert the initial 3 packages that were
> added and I will plan to pull in any updates that were made as part of
> those initial commits (I believe libsemanage had a misc patch)?
>
>
Thanks,
Matt