[Rpm-maint] RPM 4.9 Release Timeline?
pmatilai at laiskiainen.org
Tue Oct 12 07:20:31 UTC 2010
On Wed, 6 Oct 2010, Ware, Ryan R wrote:
> On 10/5/10 11:09 PM, "Panu Matilainen" <pmatilai at laiskiainen.org> wrote:
>> On Tue, 5 Oct 2010, Ware, Ryan R wrote:
>>> Hello Everyone,
>>> New here. Looking through the RPM mail archives and web site, I wasn't
>>> to find the answer to the question on my mind.
>> Oops, we even have the 4.8.0 roadmap still open despite having been
>> released many, many moons ago, never mind any new information... :-/ Will
> Yeah, I knew what I saw there wasn't up to date. Sometimes time for
> documentation just doesn't happen.
>>> I'm trying to find out what the release timeline is for 4.9. For the
>>> Mobile Simplified Security Framework (MSSF) that we want to release in
>>> MeeGo 1.2, we would like to utilize the plugin functionality that was
>>> created for SELinux. We'd really rather not backport the changes to
>>> Any rough timeframe would be helpful.
>> The idea is to a beta out in November and final in December / early
>> January, depending on how things go with the beta. So fairly soon in any
> That might be a little late depending on what we're looking for. If I
> might ask, what's driving this timeline? Is it a resource issue?
> Alignment target with other projects? Something else I'm completely
> ignorant of?
Mostly just "the fastest schedule I think we can manage to pull off."
The current development cycle has gone on longer and drifted further out
than I'd like, and because of that there's a fair amount of finishing off
work-in-progress API's and features work to do before we can make a
It's not entirely unlike having overslept and then scrambling to get to
work as fast as you can to minimize the damage :) Calling it bad planning
and release management is also applicable...
>> Note however that the collections/plugins system has some open
>> questions/issues still and WILL change to some extent, and unless those
>> odds and ends get sorted out before the beta (which is of course what we
>> want, but time's getting a bit short), it'll be marked experimental in
>> next release to allow room to make those changes in the nearish future.
>> you'll want to proceed cautiously when planning / building something
>> fundamentally important on top of it right now.
> If there is anything we can do from the MeeGo side of things to help get
> some of those odds and ends sorted out for you, please let me know. I
> understand that having a plugin infrastructure is a totally new thing for
> RPM and it's going to be an exercise in feeling out how things go for a
> while and that things will change as we go forward.
Wider-scale testing of HEAD + reporting any oddities would be helpful
certainly, extra bonus for fixing any regressions found - I'm sure there
are /some/ regressions the test-suite + our own day-to-day testing hasn't
>> Can you share some information on what are you planning to do with the
>> plugin functionality? Something akin to the SELinux plugin I presume?
> No, I want to keep everyone outside MeeGo completely in the dark. ;-)
> MeeGo will have a security framework that will heavily leverage SMACK and
> IMA/EVM. When packages are installed, we need to be able to set SMACK
> labels, calculate/verify/set the digsigsum's and run scripts with specific
> credentials. I know that the plugin will not support all we need with
> respect to this. For example, there is no plugin support for getting
> called right after a file has been extracted which would seem to be the
> optimal time (from a security perspective) to handle the digsigsum and
> SMACK label. Also, running installation scripts with separate credentials
> can't be done from the plugin. RPM does support doing both of these
> things for SELinux, but the functionality to do that resides outside of
> the plugin in older code. I would actually love to see some of this
> functionality that was created for SELinux in other parts of the RPM code
> base migrate into the plugin so that others can utilize the functionality,
> but I also understand the limited scope of the plugin as it currently
Ok. Work towards abstracting SELinux specifics out of core rpm into
plugin(s), enabling use of other similar (security) frameworks to be used
without changing rpm itself, would be very welcome. Perhaps too late to
get into rpm 4.9.0 at this point but there's always the next release :)
> Does that all make sense? Am I missing something that you had interest in?
Makes sense, sure. I basically just wanted to know what aspects of the
plugin/collection system you're interested in and the above answers that
quite sufficiently, thanks.
- Panu -
More information about the Rpm-maint